FILE  COPY 


/ Si 


ESD-TR-75-301,  Volume  II 


MTR-3067,  Volume  H 


ON-LINE  VEHICLE  MAINTENANCE  DATA  MANAGEMENT: 


MODEL  SYSTEM  SPECIFICATION  AND  TEST  RESULTS 


DEPUTY  FOR  COMMAND  AND  MANAGEMENT  SYSTEMS 

ELECTRONIC  SYSTEMS  DIVISION 
AIR  FORCE  SYSTEMS  COMMAND 
UNITED  STATES  AIR  FORCE 
Hanscom  Air  Force  Base,  Bedford,  Massachusetts 


DECEMBER  1975 


Prepared  for 


Project  No.  522E 


Approved  for  public  release; 
distribution  unlimited. 


Prepared  by 

THE  MITRE  CORPORATION 
Bedford,  Massachusetts 


Contract  No.  F19628-75-C-0001 


When  U S.  Government  drawings,  specifications, 
or  other  data  are  used  for  any  purpose  other 
than  a definitely  related  government  procurement 
operation,  the  government  thereby  incurs  no 
responsibility  nor  any  obligation  whatsoever;  and 
the  fact  that  the  government  may  have  formu- 
lated, furnished,  or  in  any  way  supplied  the  said 
drawings,  specifications,  or  other  data  is  not  to  be 
regarded  by  implication  or  otherwise,  as  in  any 
manner  licensing  the  holder  or  any  other  person 
or  corporation,  or  conveying  any  rights  or  per- 
mission to  manufacture,  use,  or  sell  any  patented 
invention  that  may  in  any  way  be  related  thereto. 


Do  not  return  this  copy.  Retain  or  destroy. 


REVIEW  AND  APPROVAL 


This  technical  report  has  been  reviewed  and  is  approved  for  publication. 


ALPHONSO  J.  OHJCHOWSKI,  JR.,  CAPT 
Project  Engineer 


PI  GS-14 

Pj 


Director,  Information  Systems 

Technology  Applications  Office 

Deputy  for  Command  and  Management  Systems 


UNCLASSIFIED 


SECURITY  CLASSIFICATION  OF  THIS  PAGE  (When  Data  Entered) 


REPORT  DOCUMENTATION  PAGE 

READ  INSTRUCTIONS 
BEFORE  COMPLETING  FORM 

i.  report  number 

ESD-TR-75-301,  Volume  II 

2 GOVT  ACCESSION  NO. 

3.  RECIPIENT’S  CATALOG  NUMBER 

A.  TITLE  (and  Subtitle) 

ON-LINE  VEHICLE  MAINTENANCE  DATA 
MANAGEMENT:  MODEL  SYSTEM  SPECIFICATION 
AND  TEST  RESULTS 

5.  TYPE  OF  REPORT  & PERIOD  COVERED 

6 PERFORMING  ORG.  REPORT  NUMBER 

MTR-3067,  Volume  II 

7.  AUTHOR(a) 

N.  B.  Sutherland 

0 CONTRACT  OR  GRANT  NUMBERfa) 

F19628-75-C-0001 

9.  PERFORMING  ORGANIZATION  NAME  AND  ADDRESS 

The  MITRE  Corporation 
Box  208 

Bedford,  Mass.  01730 

10.  PROGRAM  ELEMENT.  PROJECT,  TASK 
AREA  4 WORK  UNIT  NUMBERS 

Project  No.  522E 

11.  CONTROLLING  OFFICE  NAME  AND  ADDRESS 

Deputy  for  Command  and  Management  Systems 

Electronic  Systems  Division,  AFSC 

Hanscom  Air  Force  Base,  Bedford,  Mass.  01731 

12.  REPORT  DATE 

DECEMBER  1975 

13.  NUMBER  OF  PAGES 

123 

14.  MONITORING  AGENCY  NAME  a ADDRESSfif  different  from  Controlling  Office) 

15.  SECURITY  CLASS,  (o  1 thle  report) 

UNCLASSIFIED 

15a.  DECLASSIFICATION  DOWNGRADING 
SCHEDULE 

16.  DISTRIBUTION  STATEMENT  (of  this  Report) 


Approved  for  public  release;  distribution  unlimited. 


[ '7.  DISTRIBUTION  STATEMENT  (of  the  abstract  entered  in  Block  20,  it  different  from  Report) 


18  SUPPLEMENTARY  NOTES 


19.  KEY  WORDS  ( Continue  on  reverse  side  if  necessary  and  identity  by  block  number) 

VEHICLE  MAINTENANCE  DATA  MANAGEMENT 
VIMS 


20.  ABSTRACT  ( Continue  on  reverse  side  if  necessary  and  identify  by  block  number) 

Air  Force  vehicle  maintenance  data  management  is  supported  by  the  Vehicle 
Integrated  Management  System  (VIMS),  a standard  base-level  batch  data  system. 
Functions  which  could  profit  from  on-line  access  to  VIMS  were  identified  and  in- 
corporated into  an  on-line  system  model  in  the  Data  Handling  Applications  Center. 
Teams  of  vehicle  maintenance  specialists  were  brought  to  the  Center  to  evaluate  the 
model.  Their  comments,  together  with  the  model  specification,  form  a requirements 
and  design  base  for  an  operational  prototype  system. 

DD  , j°"M73  1 473  edition  OF  1 NOV  65  IS  OBSOLETE  UNCLASSIFIED 


SECURITY  CLASSIFICATION  OF  THIS  PAGE  (When  Data  Entered) 


UNCLASSIFIED 

SECURITY  CLASSIFICATION  OF  THIS  PAGE(lFh«n  Date  Enter'd) 


UNCLASSIFIED 


» 


SECURITY  CLASSIFICATION  OF  THIS  PAGEfWhen  Date  Entered) 


4 


LIST  OF  ILLUSTRATIONS 


TABLE  OF  CONTENTS 


PaSe 

4 


I 


LIST  OF  TABLES 


5 


SECTION  I INTRODUCTION  7 

BACKGROUND  7 

RESULTS  IN  BRIEF  8 

SCOPE  OF  THIS  REPORT  8 


SECTION  II  TEST  OBJECTIVES  9 

SECTION  III  MODEL  AND  TEST  ENVIRONMENT  10 

GENERAL  10 

MODEL  ENVIRONMENT  10 

MODEL  SOFTWARE  11 

DATA  FILES  12 

TEST  SUBJECTS  13 

TEST  PROCEDURE  15 


SECTION  IV  TRANSACTIONAL  DESCRIPTIONS  18 

GENERAL  18 

SYSTEM  CODES  18 

ACTION  CODES  18 

SITE  CODES  21 

TRANSACTIONS  - WORKLOAD  CONTROL  23 

Open  Work  Order  23 

Amend  Work  Order  31 

Close  Work  Order  32 

Display  Status  of  Work  Order  File  35 

VDP  ON  Procedure  35 

VDP  OFF  Procedure  38 

Add  Job  to  Deferred  Maintenance  File  39 

Change  Job  in  Deferred  Maintenance  File  41 

Delete  Job  from  Deferred  Maintenance  File  41 

TCTO  Procedure  43 

TRANSACTIONS  - MATERIEL  CONTROL  47 

Review  Back-Ordered  Parts  Status  47 

Add  Item  to  Back-Ordered  Parts  File  47 

Change  Item  in  Back-Ordered  Parts  File  50 

Delete  Item  from  Back-Ordered  Parts  File  52 

Report  Issue  of  Back-Ordered  Parts  52 


1 


TABLE  OF  CONTENTS  (Continued)  Page 

Review  High  Cost  Bench  Stock  Master  File  54 

Add  Item  to  High  Cost  Bench  Stock  Master  File  56 

Change  High  Cost  Bench  Stock  Master  File  Entry  56 

Delete  High  Cost  Bench  Stock  Master  File  Entry  59 

Issue  High  Cost  Bench  Stock  Item  59 

VDP  Summary  Display  61 

Input  COPARS  Cost  Data  63 

TRANSACTIONS  - REPORTS  AND  ANALYSIS  (R&A)  68 

Update  Scheduled  Maintenance  68 

Update  Historical  Repair  File  68 

Update  Parts  Warranty  File  71 

Fuel/Oil  Issue  Transaction  71 

Manhour  Reporting  72 

Error  Correction  for  Manhour  Reporting  76 

SECTION  V COMMENTS  DURING  TESTING  (SUMMARIZED  AND  ANNOTATED)  79 

DISCUSSION  79 

COMMENTS  79 

1.  OPEN  79 

2.  AMEND  87 

3.  CLOSE  89 

4.  RESUME  91 

.5.  WO/REVIEW  91 

6.  V DP/ON  92 

7.  VDP/OFF  93 

8.  DEFER/ADD  93 

9.  DEFER/CHANGE  95 

10.  DEFER/DELETE  95 

11.  PARTS/REVIEW  95 

12.  PARTS/ADD  96 

13.  PARTS/CHANGE  97 

14.  PARTS/DELETE  98 

15.  PARTS/ISSUE  98 

1b.  HCBS/ REVIEW  100 

17.  HCBS/ ADD  100 

18.  HCBS/CHANGE  101 


2 


TABLE  OF  CONTENTS  (Concluded)  Page 

19.  HCBS/DELETE  101 

20.  HCBS/ISSUE  101 

21.  COPARS  102 

22.  FUEL  105 

23.  TIME/INPUT  107 

24.  TIME/EDIT  109 

25.  VDP/SUMMARY  109 

26.  WARRANTY/UPDATE  109 

27.  SPECIAL  INQUIRIES  110 

28.  KEYBOARD  111 

29.  GENERAL  111 

SECTION  VI  SUMMARY  115 

SPECIFIC  DESIGN  GUIDANCE  115 

GENERAL  DESIGN  GUIDANCE  115 

POTENTIAL  USER  ACCEPTANCE  116 

THE  MODELING  APPROACH  117 

APPENDIX  I SAMPLE  COMMENTS  FROM  EVALUATION  FORMS  119 


3 


LIST  OF  ILLUSTRATIONS 


Figure  Number 


Page 


1 ATC  - Proposed  System  Codes 

2 Scheduled  Maintenance  as  Displayed  During  OPEN 

3 Deferred  Maintenance  as  Displayed  During  OPEN 

4 Work  Order  as  Initially  Displayed  During  OPEN 

5 Shop  Copy  of  Work  Order 

6 Work  Order  at  Completion  of  CLOSE 

7 Deferred  Maintenance  List  to  be  Carried  in  Vehicle 

8 Work  Order  File  Summary  Display 

9 Displayed  Form  for  DEFER/ADD 

10  Parts  Request  Generated  by  DEFER/ADD 

1 1 Form  for  Entry  of  TCTO  Search  Data 

12  TCTO  Deferred  Job  Entry  Form 

13  Page  of  Back-Ordered  Parts  File  as  Displayed 

by  PARTS/REVIEW 

14  Displayed  Form  for  PARTS/ADD 

15  Display  for  PARTS/CHANGE  or  PARTS/DELETE 

16  Parts  Arrival  Notification 

17  Display  During  PARTS/ISSUE 

18  Page  1 of  High  Cost  Bench  Stock  File  as 

Displayed  by  HCBS/ REVIEW 

19  Displayed  Form  for  Adding  Item  to  HCBS  File 

20  Item  Displayed  for  HC BS/CHANGE 

21  Displayed  Form  for  HCBS/ISSUE 

22  VDP  Summary  Display 

23  Parts  warranty  Display 

24  COPARS  Sales  Slip  Data  Entry  Form 

25  Scheduled  Maintenance  Update  Form 

26  Historical  Maintenance  Update  Form 

27  Displayed  Form  for  Fuel/Oil  Issue  Data  Entry 

28  Displayed  Form  for  TIME/INPUT 

29  Error  Suspense  File  Generated  from  TIME/INPUT 


19 

24 

25 

26 
30 
33 

36 

37 
40 
42 

44 

45 

48 

49 
51 
53 
55 

57 

58 
60 
62 

64 

65 

66 

69 

70 
73 
75 
77 


4 


Table  Number 


LIST  OF  TABLES 


I Test  Subjects:  Duty  Station,  Work  Center  Assignment, 
Air  Force  Experience  and  Test  Team  Assignment 


Page 

14 


5 


SECTION  I 


INTRODUCTION 


BACKGROUND 

The  Vehicle  Integrated  Management  System  (VIMS)  is  a base-level 
management  system  that  processes  data  related  to  vehicle 
maintenance.  The  Air  Force  currently  has  more  than  100,000  vehicles 
being  maintained  at  approximately  500  sites.  Most  of  these  sites 
are  Air  Force  bases,  where  vehicle  maintenance  data  is  collected  and 
processed  daily  on  the  Burroughs  B3500  computer.  The  daily,  weekly 
and  monthly  reports  generated  by  VIMS  provide  the  necessary  data  to 
support  vehicle  maintenance  management  at  all  levels,  including 
daily  operations,  squadron  level,  and  higher  headquarters  management 
of  the  fleet. 

The  Directorate  of  Logistics  Systems  at  the  Air  Force  Data 
Systems  Design  Center  (AFDSDC)  is  responsible  for  the  implementation 
and  maintenance  of  the  VIMS  software  and  for  the  establishment  of 
the  operational  procedures  for  its  use.  In  the  latter  part  of  FY71*, 
ESD/MITRE  conducted  a brief  study  and  evaluation  of  VIMS  for  AFDSDC 
that  explored  possible  alternative  techniques  for  improving  the 
handling  of  vehicle  maintenance  management  data.  The  results  of 
that  study  were  reported  in  ESD-TR-75-1,  "Air  Force  Vehicle 
Integrated  Management  System  (VIMS)  Data  Handling  Study" 

This  report  presented  some  perceived  strengths  and  weaknesses  of 
VIMS  and  suggested  a number  of  near  term  improvements  such  as  the 
clarification  of  output  reports  through  reformatting.  The  primary 
conclusion  was  that  vehicle  maintenance  operations  and  management 
could  benefit  from  on-line  access  to  VIMS  through  terminals  located 
in  certain  key  work  centers. 

As  a result  of  the  FY74  study,  a FY75  follow-on  effort  was 
conducted,  with  the  objective  of  developing  the  alternatives  for  an 
AFDSDC  decision  regarding  the  implementation  of  an  on-line  VIMS 
prototype. 

In  the  follow-on  effort,  an  analysis  was  made  of  those  VIMS- 
r elated  functions  currently  being  performed  that  might  be 
accomplished  advantageously  in  an  on-line  mode.  To  show  how  this 
might  be  done,  a set  of  transactions  was  proposed.  Each  transaction 
was  specified  in  enough  detail  to  show  how  an  on-line  capability 
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might  be  used  to  assist  in  accomplishing  a specific  VIMS-related 
task. 


The  proposed  transactions  were  implemented  in  a computer-based 
development  model  of  on-line  VIMS.  The  model  was  implemented  in  the 
ESD/MITRE  Data  Handling  Applications  Center  as  a design  tool  to 
assist  in  the  subsequent  preparation  of  specifications  for  a full 
on-line  prototype.  After  the  model  was  completed,  it  was  tested  for 
a period  of  three  weeks  by  a total  of  ten  persons  who  are  currently 
assigned  to  the  vehicle  maintenance  area  at  a number  of  Air  Force 
bases.  This  paper  reports  on  the  results  of  that  testing. 


RESULTS  IN  BRIEF 

The  primary  result  of  the  testing  was  the  accumulation  of  a 
large  number  of  specific  comments  and  suggestions  that  will  serve  as 
guidance  for  any  subsequent  development  of  specifications  for  on- 
line VIMS.  Testing  also  generated  a number  of  more  general 
guidelines  to  specification  of  any  similar  on-line  system. 

Acceptance  of  the  on-line  approach  was  uniformly  high  among  all 
ten  subjects.  This  was  attributable  to  the  fact  that  1)  current 
manual  procedures  were  strongly  paralleled  in  the  on-line 
procedures,  2)  the  on-line  procedures  provided  some  immediate  and 
apparent  benefits  to  the  user,  and  3)  the  model  design  allowed  the 
user  to  remain  in  control  over  the  computer. 

It  was  concluded  that  the  development  and  testing  of  a model  by 
functional  personnel  is  an  effective  approach  to  system  design. 


SCOPE  OF  THIS  REPORT 

Section  II  presents  the  test  objectives.  Section  III  gives  a 
brief  description  of  the  test  environment,  model  software  and  data 
files,  and  discusses  the  test  subjects  and  test  procedure.  Section 

IV  is  a detailed  description  of  the  transactions  proposed  to  date 
for  on-line  VIMS,  updated  to  reflect  how  they  were  implemented  in 
the  model  and  hence  how  they  appeared  to  the  test  subjects.  Section 

V contains  the  comments  and  suggestions  obtained  during  testing 
(sorted,  summarized  and  annotated).  Section  VI  summarizes  the  test 
results.  Appendix  I contains  a sample  of  comments  taken  directly 
from  the  test  subjects'  evaluations  of  the  model. 
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SECTION  II 


TEST  OBJECTIVES 

The  transactions  specified  for  the  proposed  on-line  VIMS  do  not 
represent  a major  departure  from  the  current  batch-oriented  VIMS 
procedures.  The  transactions  are  generally  designed  to  assist  with 
specific  tasks  presently  performed  at  three  work  centers  in  the 
vehicle  maintenance  area;  namely,  Workload  Control,  Materiel  Control 
and  Reports  & Analysis  (R&A).  The  model  was  designed  to  give  a 
realistic  view  of  how  operators  at  the  three  work  centers  would 
interact  with  VIMS  to  perform  these  tasks  in  on-line  mode. 

The  testing  with  functional  area  personnel  was  intended  to 
determine  if  the  on-line  procedures  as  specified  and  modeled  were 
adequate  to  permit  the  operators  to  properly  complete  their  tasks. 

It  was  also  intended  to  determine  if  the  procedures  were 
operationally  acceptable  to  a user  in  terms  of  dialog,  visual 
display  formats  and  content,  data  entry  conventions  and  other 
operator  actions. 

The  primary  objective  was  early  involvement  of  the  end  user 
during  the  development  stages  of  the  on-line  concept,  and  to  use 
this  involvement  to  obtain  evaluative  feedback  to  serve  as  guidance 
for  the  specification  of  a full  prototype. 
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SECTION  III 


MODEL  AND  TEST  ENVIRONMENT 


GENERAL 

The  model  comprises  a set  of  computer  programs  that  will  respond 
to  and  interact  with  an  operator  as  he  performs  a variety  of  on-line 
VIMS  transactions.  The  transactions  are  initiated  and  controlled 
from  a CRT  terminal.  The  modeled  transactions  represent  procedures 
that  would  be  followed  at  a terminal  located  in  the  three  work 
centers  mentioned  previously:  Workload  Control,  Materiel  Control, 

and  R&A.  In  addition  to  the  CRT  terminal,  it  is  assumed  that  a 
printer  would  be  available  to  each  work  center  in  order  to  obtain 
immediate  hard  copy  as  needed. 


MODEL  ENVIRONMENT 

The  model  was  written  in  ALGOL  for  the  Data  General  NOVA 
minicomputer  in  the  ESD/MITRE  Data  Handling  Applications  Center. 
The  Center  contains  a NOVA  800  with  32,768  words  of  16-bit  core 
memory,  and  a large  selection  of  peripheral  devices.  The  Center 
runs  under  Data  General's  Real-Time  Disk-based  Operating  System. 
System  devices  supported  directly  by  operating  system  commands 
include: 


• Fixed-Head  Disk  (1/4  M words) 

• Magnetic  Tape  (9-track,  45  ips) 

• Card  Reader  (400  cpm) 

• Line  Printer  (356  1pm) 

• High  Speed  Paper  Tape  Reader  (400  cps) 

• Console  Teletype  (10  cps) 

• Console  CRT  (120  cps) 

• Real-Time  Clock 

A number  of  non-system  devices  have  been  interfaced  to  the  NOVA 
and  are  supported  by  MITRE-developed  software.  The  following  non- 
system device  is  required  by  the  model: 
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CRT/Kevboard  Display  Station  - This  is  a Delta  Data  5200 
Terminal  with  3072  characters  of  scrolling  refresh  memory,  a 
display  area  of  27  lines  of  80  characters,  and  extensive  local 
editing  features.  Transfer  of  data  between  the  CRT  and  the  NOVA 
may  be  one  character  at  a time  or  by  block  at  speeds  up  to  2400 
bps. 

The  printer  that  was  used  during  model  testing  was  the  system- 
supported  356  1pm  printer. 


MODEL  SOFTWARE 

The  model  software  consists  of  a main  loop  and  a set  of 
transaction  modules.  The  main  loop  is  the  control  program  that 
responds  to  an  operator's  initial  request  for  service  from  a 
terminal  and  passes  control  to  the  appropriate  transaction  module. 
Upon  completion  of  a transaction,  control  is  returned  to  the  main 
loop. 

The  following  is  a list  of  the  transaction  modules  that  were 
implemented  in  the  model,  with  an  indication  of  the  work  center  for 
which  the  transaction  is  intended.  Complete  functional  descriptions 
of  the  transactions  may  be  found  in  Section  IV. 

Workload  Control 


a.  OPEN . Used  to  open  a work  order. 

b.  RESUME.  Used  to  resume  opening  a work  order  temporarily 
suspended  because  one-time  repair  limit  is  exceeded. 

c.  AMEND.  Used  to  retrieve  an  open  work  order  for  review  and/or 
amendment. 

d.  VDP/ON.  Suspend  a work  order  and  put  vehicle  on  VDP. 

e.  VD P/OFF.  Remove  a vehicle  from  VDP  and  re-activate  a work 
order. 

f.  CLOSE.  Close  a work  order  and  report  disposition  of  all  jobs. 

g.  WO/REVIEW.  Display  status  of  all  work  orders. 

h.  DEFER/ADD  (CHANGE) (DELETE) . Used  to  make  direct  additions, 
changes  and  deletions  to  the  deferred  maintenance  file. 
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Materiel  Control 


a.  PARTS/REVIEW.  Display  back-ordered  parts  file  and  allow  paging 
for  review. 

b.  PARTS/ADD  (CHANGE) (DELETE) . Used  to  make  additions,  changes  and 
deletions  to  the  back-ordered  parts  file. 

c.  PARTS/ISSUE.  Issue  parts  out  of  the  back-ordered  parts  file 
against  a work  order. 

d.  HCBS/ REVIEW.  Display  high  cost  bench  stock  file  and  allow 
paging  for  review. 

e.  HCBS/ADD  (CHANGE) (DELETE) . Used  to  add,  change  or  delete  items 
from  the  high  cost  bench  stock  master  file. 

f.  HCBS/ISSUE.  Issue  high  cost  bench  stock  items  against  work 
orders. 

g.  COPARS.  Used  to  process  COPARS  sales  slips. 

Reports  & Analysis 

a.  FUEL . Process  Fuel/Oil  issue  slips. 

b.  TIME/INPUT.  Process  employee  time  cards. 

c.  TIME/EDIT.  Process  error  suspense  file  generated  during 
TIME/INPUT. 


DATA  FILES 

The  model  was  operated  using  a test  data  base  that  was  created 
to  represent  a 100-vehicle  fleet.  The  content  and  structure  of  the 
files  were  selected  for  expediency  in  developing  the  model,  and  do 
not  represent  the  content  or  structure  of  the  files  that  would  be 
required  for  a complete  prototype.  Thus  the  test  files  contain  only 
a subset  of  the  data  required  for  a full  prototype,  and  are 
maintained  and  updated  by  the  model  only  to  the  extent  necessary  to 
preserve  the  realism  and  integrity  of  the  transaction  modules  as 
viewed  by  an  operator  at  a terminal.  For  example,  jobs  that  are 
added  to  a work  order  will  be  preserved  since  the  updated  work  order 
will  be  displayed  and  used  in  other  transactions.  On  the  other 
hand,  inputs  such  as  charging  of  parts  cost  to  a vehicle  will  not  be 
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saved,  since  this  data  is  not  referred  to  again  in  the  model  once  it 

is  entered. 

The  files  developed  for  the  model  include: 

a.  VEHICLE  MASTER.  Contains  data  for  100  vehicles.  Includes 
static  data  for  each  vehicle  and  complete  scheduled  maintenance 
data  for  each  vehicle  (this  file  was  created  using  actual  data 
for  100  vehicles  from  the  fleet  at  Hanscom  AFB) . 

b.  VEHICLE  HISTORICAL  REPAIR.  Contains  maintenance  repair  history 
for  100  vehicles  for  previous  six  months  (uses  Air  Training 
Command  (ATC)-proposed  expanded  set  of  vehicle  system  codes). 

c.  EMPLOYEE  MASTER.  Contains  employee  name,  SSAN  and  assigned  work 
center  for  30  (fictitious)  employees. 

d.  HIGH  COST  BENCH  STOCK.  Contains  FSN's,  cost,  charge  codes  and 
descriptions  of  120  HCBS  items  (taken  from  HCBS  file  at  Hanscom 
AFB). 

e.  WORK  ORDER.  Contains  copies  of  all  work  orders  currently  open, 
VDP-suspended  or  closed  less  than  six  days  (the  file  was 
initially  loaded  with  32  work  orders,  simulating  two  days  of 
activi ty) . 

f.  DEFERRED  MAINTENANCE.  Contains  a record  of  all  jobs  either 
deferred  or  VDP-suspended  (the  file  was  loaded  with  26  jobs, 
deferred  against  20  vehicles). 

g.  BACK-ORDERED  PARTS.  Contains  data  on  all  parts  on  order,  or 
back-ordered  and  received  but  not  yet  installed  (the  file  was 
loaded  with  data  for  31  parts,  ordered  against  22  deferred  or 
VDP  jobs). 

h.  PARTS  WARRANTY.  Contains  data  on  all  parts  installed  on  fleet 
vehicles  for  which  a special  warranty  is  still  current  (the  file 
was  loaded  with  36  warranty  items). 


TEST  SUBJECTS 

Ten  subjects  participated  in  the  testing.  They  were  selected 
from  six  Air  Force  bases  across  five  commands,  including  one  subject 
from  Hahn,  Germany,  representing  USAFE.  Table  I shows  the 
distribution  of  subjects  according  to  their  respective  bases  and 
work  center  assignments.  By  work  center  assignment,  four  were  from 
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TABLE  I 


Test  Subjects:  Duty  Station,  Work  Center  Assignment, 

Air  Force  Experience  and  Test  Team  Assignment 


ASSIGNED 
^\WORK 
DUTY  \£ENTEF 
STATION 

Workload 

Control 

Materiel 

Control 

! 

Reports  & 
Analysis 

TEAM  1 
3 days 

Hans com  - AFSC 

X (32) 

X (28) 

x (15) 

TEAM  2 
5 days 

Shaw-  TAC 

X (7) 

Langley-  TAC 

X (3-5) 

X (20) 

Hahn-  USAFE 

X (6.5) 

TEAM  3 
4 days 

Dover-  MAC 

X (20) 

Pease-  SAC 

X (16) 

X (7) 

( ):  No.  of  Years  Air  Force  Experience 
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Workload  Control,  three  were  from  Materiel  Control  and  three  were 
from  R&A.  Table  I shows  each  subject's  total  years  with  the  Air 
Force.  The  combined  experience  of  all  subjects  represents  155 
years,  most  of  which  has  been  in  the  vehicle  or  aircraft  maintenance 
area.  Table  I also  shows  how  subjects  were  grouped  into  test  teams, 
and  the  duration  of  testing  for  each  team. 

The  selection,  scheduling  and  coordination  of  test  subjects  were 
all  handled  by  a representative  of  AFDSDC. 


TEST  PROCEDURE 
Preparation 

After  the  model  was  completed,  it  was  subjected  to  a period  of 
in-house  testing  by  project  personnel.  Three  members  of  the  MITRE 
technical  staff  and  the  ESD  project  officer  each  spent  from  one  to 
two  days  in  testing.  Their  comments  were  recorded,  and  are 
reflected  in  some  of  the  material  presented  in  Section  V.  Where 
possible,  their  comments  and  suggestions  were  incorporated  in  a 
subsequent  "last  pass"  through  the  model  software  in  which  final 
modifications  and  corrections  were  made  prior  to  the  arrival  of 
functional  area  personnel. 

During  this  period  of  time  the  necessary  training  and  test 
materials  were  prepared.  A package  of  test  cases  was  developed  to 
insure  that  as  many  specific  features  of  each  transaction  as 
possible  would  be  exercised  during  the  testing.  Where  possible, 
each  case  was  accompanied  by  its  appropriate  source  document 
(Operator  Inspection  Guide  for  the  OPEN  transaction,  annotated  work 
orders  for  the  AMEND  and  CLOSE  transaction,  Employee  Labor  Cards  for 
TIME/INPUT,  etc.).  A similar,  abbreviated  package  was  prepared  for 
use  during  the  demonstration  and  training  phase  of  testing. 

Testing 

Introduction 


When  each  team  arrived  they  were  given  about  an  hour  of 
introductory  discussion.  Subjects  were  assured  that  they  were  not 
being  tested  or  evaluated  in  any  way.  It  was  emphasized  that  they 
were  there  to  help  evaluate  a proposed  system  in  its  early 
development  stage,  and  that  their  comments  would  provide  guidance 
that  would  help  to  shape  the  final  system  when  and  if  it  were  to  be 
implemented. 
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Subjects  were  introduced  to  the  concept  of  on-line  VIMS  and  the 
nature  of  the  model  was  explained.  The  model  was  described  as  a 
"fast  file  clerk,"  able  to  perform  many  routine  clerical  tasks 
rapidly  and  consistently.  It  was  emphasized  that  the  operator  of 
the  CRT  was  always  in  control,  and  always  retained  the  decision- 
making prerogative;  the  "file  clerk"  was  there  to  assist  only  as 
directed. 

The  concept  was  illustrated  by  talking  through  one  transaction. 

A list  of  all  of  the  transactions  implemented  in  the  model  was 
presented  but  not  explained  at  this  time.  Subjects  were  given  a set 
of  simplified  flow  diagrams  and  descriptions  of  the  transactions  to 
keep  and  study  at  their  leisure. 

Each  subject  was  given  a folder  containing  a personal  history 
form,  evaluation  forms  to  be  used  at  the  end  of  testing,  and  several 
sheets  of  blank  paper.  Subjects  were  encouraged  to  write  down  as 
many  questions,  comments  and  suggestions  as  possible  throughout  the 
test  period. 

Demonstration  and  Training 

The  balance  of  day  one  for  each  team  was  devoted  to 
demonstration  and . training,  conducted  at  the  CRT  terminal.  Using 
the  demonstration  package  of  test  cases,  a quick  pass  was  made 
through  every  transaction  to  give  an  overview  of  the  entire  model. 

In  this  way  it  was  possible  to  explain  the  use  of  the  CRT  and 
function  keys  in  specific  context  rather  than  in  the  abstract.  So 
much  comment  was  elicited  during  this  first  run-through  that  the 
demonstration  period  tended  to  run  longer  than  had  been  expected. 

Testing 

The  general  schedule  for  testing  each  day  was: 

1 hr.  discussion 
3 hrs.  testing 
lunch 

1 hr.  discussion 
3 hrs.  testing 

although  the  three  hour  testing  session  after  lunch  was  shortened 
for  later  teams  to  allow  some  discussion  time  before  quitting  for 
the  night. 

The  team  member  from  the  appropriate  work  center  operated  the 
terminal  when  testing  those  transactions  pertaining  to  his 
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particular  area.  Test  cases  were  presented  one  by  one  to  the 
subject  from  the  package  mentioned  previously*  The  subject  was 
given  the  prop  simulating  the  appropriate  source  document,  with  a 
brief  explanation  of  the  transaction  he  was  to  perform,  and  then  was 
allowed  to  proceed  on  his  own  to  execute  the  transaction.  Other 
team  members  grouped  around  the  CRT  and  observed.  All  team  members 
were  encouraged  to  ask  questions  or  to  comment  at  any  time. 

This  approach  proved  to  be  very  satisfactory  in  terms  of  team 
involvement.  There  was  a great  deal  of  active  discussion  and 
interplay  that  produced  a high  volume  of  comments  and  suggestions, 
as  may  be  seen  in  Section  V.  It  was  particularly  helpful  to  have 
all  three  major  work  centers  represented.  As  a result  the  impact  of 
a transaction  on  other  functional  areas  could  be  examined  and 
discussed,  and  the  implications  of  suggested  changes  could  be 
explored  across  work  centers.  This  kind  of  exchange  and  interplay 
produced  comments  and  suggestions  that  should  lead  to  a more  tightly 
integrated  package  of  transactions  and  procedures. 

Data  Collection 


Two  observers  (a  MITRE  technical  staff  member  and  a 
representative  of  AFDSDC)  recorded  comments  throughout  the 
introductory,  training  and  testing  periods.  At  any  time  during 
testing,  specific  points  were  addressed  and  talked  through  as  they 
came  up.  As  a result,  many  of  the  "comments1*  that  were  recorded^ 
were  not  the  subjects'  raw  comments  but  were  rather  the  observer's 
condensation  of  the  essence  of  a group  discussion. 

Subjects  also  wrote  their  own  comments  in  their  folders  during 
the  discussion  periods,  during  testing  (when  they  were  acting  as 
observers),  and  during  off  hours.  Each  subject  also  filled  out  an 
evaluation  questionnaire  at  the  completion  of  the  testing. 

An  oral  debriefing  was  conducted  with  each  team  at  the  end  of 
their  test  period.  These  debriefing  sessions  were  tape  recorded  and 
the  tapes  were  given  to  the  AFDSDC  representative. 
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SECTION  IV 


TRANSACTIONAL  DESCRIPTIONS 


GENERAL 

Prior  to  the  programming  of  the  model,  a set  of  transactions  was 
specified  and  coordinated  with  the  Data  Services  Design  Center.  The 
following  section  repeats  those  transactional  descriptions,  updated 
to  reflect  how  they  were  finally  implemented  in  the  model  and  hence 
how  they  appeared  to  the  test  subjects.  Any  transactions  or  features 
within  a transaction  that  were  specified  but  not  implemented  in  the 
model  are  enclosed  in  brackets. 


SYSTEM  CODES 

The  system  codes  now  used  on  the  Vehicle  Historical  Record  to 
indicate  the  vehicle  subsystem(s)  that  were  repaired  are  not 
granular  enough  to  accurately  identify  repetitive  maintenance.  Air 
Training  Command  has  developed  and  proposed  to  AFDSDC  an  expanded 
set  of  system  codes  that  adds  up  to  nine  subcategories  to  each  of 
forty  major  system  codes.  The  expanded  codes  as  shown  in  Figure  1 
are  used  in  the  development  model.  It  is  proposed  that  this  or  some 
similarly  expanded  set  of  codes  be  used  in  the  next  generation  of 
VIMS. 


ACTION  CODES 

In  the  proposed  on-line  VIMS  there  is  an  action  code  field 
preceding  each  job  on  the  work  order.  The  field  is  of  the  form: 

c/ccc 

The  primary  action  code  designator  is  a single  character  that 
precedes  the  slash.  Allowable  codes  include: 

A Activiate  or  Assign 
D Defer 
S Suspend 

P Post  as  complete 
K Kill  or  cancel  job 
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1 valves 

2 bMdi 

oiling  system/ sending  unit/gauge 
pulleys/sprockets 

5 super charger /blower 

6 gasket • 

7 rl brat  loo  dugwr 

0 engine  aount 

9 expansion  plugs 

06  Ignition 

1 switch 

2 wiring 

3 resistor 
k coll 

3  distributor  cap 

6 distributor 

7 vacuus  advance 

9 rotor 

03  Electrical/ Lights 

1 wiring  harness 

2 horn  sys  tea 

3 headlight  switch 

k turn  signal  switch/*! ring/ fins her 
3 turn  slg  llghts/eoerg  flashers 

6 parking/ clearance /tall  lights 

7 headlights 

8 stop/back-up  lights 

9 Interior /instrument  lights 

Ok  Charging 

1 generator/alternator 

2 regulator/rectlfler 

3 drive  be It /pulleys 

k gen/ alt  aount log  brackets 

5 gen/ alt  brushes 

6 alternator  diodes 

7 wiring 

0 battery 

9 gauge  Indicator 

05  Starting  System 

1 solenold/relay 

2 beodlx 

3 ring  gear 
k armature 

5 fields 

6 brushes 

7 battery  cable 

8 starter  button 

9 motor /pony  engine 

06  Carburetor 

1 air  cleaner(oll  bath) 

2 air  filter  element 

3 accelerator  pedal/linkage 
k internal  fuel  filter 

5 float 

6 dash  pot 

7 choke 

0 governor 

9 intake  manifold 

07  fuel 

1 tank/ filler /cap 

2 sending  unit 

3 fuel  pusg> 

k fuel  filter 

5 fuel  lines 

6 distribution  block( diesel) 

7 Injectors 

6  selector  switch 
9 fuel  gauge 


Figure 


00  Exhaust 

1 manifold 

2 heat  riser 

3 exhaust  plpe(s) 
k muffler 

5 spark  arrestor 

6 tall  pipe 

7 banger/brackets 

0 resonator 

9 weather  cap 

09  Cooling 

1 radiator 

2 radiator  shroud 

3 fan 

k radiator  hoses 

5 shutter  system 

6 addltlves/wlnterl ration 

7 sending  unlt/tenperature  gauge 

0 water  puag> 

9 thermostat 

10  Clutch 

1 pressure  plate 

2 clutch  dlsc(s) 

3 fly  wheel 

k master  cylinder 

5 release  bearing 

6 pilot  bearing 

7 linkage/pedal 

0 release  collar/fork 
9 slave  cylinder 

11  Transmission 

1 shift  lever/linkage 

2 modulator  valve 

3 selector  box/lever  housing 

k gears 

5 ca»e/cover( s ) 

6 oil  cooler/llnes/f liter 

7 PT0  assembly 

8 transfer  case 

9 seals/gaskets 

12  Drive  8 heft /U- Joints 

1 universal  Joint 

2 center  bearing 

3 pillow  block 
k PT0  drive 

5 drive shaft,  rear 

6 drive s haft,  Intermediate 

7 dr Ives haft , front 

8 drive a haft 

9 yoke 

13  Differential 

1 carrier  assembly 

2 rlng/pinloo  gear 

3 side  bearing 

k pillion  shaft  bearing 

5 pinion  shaft  oil  seal 

6 axle  shaft 

7 spindle  shaft  bearing 

8 wheel  bearings/ seals  (rear  only) 

9 two- speed  system 

lk  Wheel  Alignment 

1 balance  wheels 

2 adjust  wheel  etope 
rotate  tires 

rim/ wheels 

5 steering  levers 

6 steering  brakes 

7 steering  wheel 

8 caster , coed>er , kingpin  Inclination 

9 toe- in/ turning  radius 


ATC  - Proposed  System  Codes 


15  Steering 

1 hydraulic  pump 

2 hydraulic  cylinder 

3 pitman/ldler  arm 
k gear  housing 

5 drag  link 

6 tie  rod/end(s) 

7 sector  shaft 

0 eeels/gasketa/ahlms/bearlngs 

9 air  booster 

16  Suspension 

1 shock  absorbers 

2 control  arm ( upper /lower) 

3 ball  Joint (upper/ lower) 

k steering  knuekle/CVU- Joints 

5 stabiliser 

6 coll  spring 

7 leaf  spring 

0 trunnion  assembly 

9 front  wheel  bearings 

17  Orates 

1 master  cylinder 

2 wheel  cylinders ) 

3 drums/discs 
k linings/pads 

5 booster  assembly 

6 pedal  linkage 

7 fluid  llnea/hoses 

8 backing  plate 

9 emerg  brake  sye(leee  cables) 

10  Air  System/ Brake s 

1 ccmgjresaor/pulley/beltB 

2 hoses/ lines /valves 

3 air  governor 
k air  reservoir 

5 slack  adjuster 

6 brake  camshaft 

7 diaphragm  assembly 

8 semi -trailer  connect  loo 

9 low  air  pres  warning  slg/gauge 

19  Vlndshlsld  Wiper 

1 wiper  motor 

2 wiper  blades 

3 viper  arms 

k transmlssl on/gear  box 

5 Linkage 

6 switch 

7 washer  system 

8 hose 

9 washer  bag 

20  Heater/ Booster 

1 core 

2 blower  motor 

3 switch 

k dash  control  assembly 

5 hoses 

6 defrosters/ducts 

7 temp  control  valve 

8 air  conditioners 

9 booster  heaters 

21  Speedometer/Houmrter 

1 bead 

2 cable 

3 casing 

k drive  gear 

5 hourmeter  prime  engines 

6 tachograph 

7 tachograph  drive 

8 tachometer 

9 tachometer  driver/sending  unit 
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22  Control  Cables 

1 throttle  cables 

2 PTO  cables 

3 choke  cables 

U emergency  brake  cables 

5 heater  control 

6 winch  cables 

7 boost  cables 

8 pulleys/ drums /blocks/ sheaves 

9 hood  release  cable 

23  Hydraulic  System 

1 hydraulic  pung> 

2 lloes/hoses 

3 levers/ controls 

U cylinders,  llft/tllt 

5 by-pass  valve 

6 outriggers 

7 PTO  drive 

8 reeervolr/level  Indicator 

9 change  oil  filters 

2*»  Turrets 

1 phasing 

2 hydraulics/ tubing/ control/ notor 

3 valves/se als/ gasket s/O- rings 
k pistol  control  assy 

5 cable s/linkage/levers 

6 ground  sweep 

7 shapers/screens 

8 gears 

9 Manual  controls 

25  Foam  C-B 

1 foam  tank 

2 foaa  bag 

3 Metering  valve 
£ control  valve 

5 foaa  puap 

6 CB  tank 

7 CB  valves 

6  level  Indicators 
9 foam  OB  piping 

26  Valves  (Other  than  Engine) 

1 Manually  operated 

2 electrically  operated 

3 hydraulically  operated 
k pneumatically  operated 

5 foaa  aeterlng/ foaa  shut-off 

6 ground  sweep 

7 priaer 

8 turret 

9 water  lock  valves 

27  Bossies 

1 valve  body 

2 gasket  s/Orlngs/seals 

3 filters 

k ground  cable/ chips 

5 flow  control 

6 cradle a /holders 

7 overwing 

8 underwlng/ single  point 

9 ground  sweep 

26  Piping,  Vster/Fuel( Plimbing&Owlng 

1 sediment  strainers  Joints) 

2 basket  strainers 

3 segre  gators 

k sensing  lines 

5 pressure  regulator/ valve 

6 coupling/ gasket 

7 O-rlng 

8 bearings 

9 support  bracket 


29  Puaplng  System/ Boses 

1  purjp  engine  (unless  prlne  mover  also) 

► 2 PTO  drive 

3 pip  assembly 
k filters 

5 control  valve 

6 saals/packlng 

7 bottom  loading  systea 

8 hose (mainline /handline ) 

9 

30  Hose  Reel /Rewind 

1 cables 

2 drive  motor 

3 solenoid 

k drive  cbaln/belts 

5 drive  sprockets 

6 switch 

7 brake  eeseably 

8 wiring 

9 Manual  rewind 

31  Refueling  Inspectloos( IAV  TO  37 K- 1-101) 

1 asters  calibrated 

2 water  segregators 

3 filters  replaced 

k line  & basket  strainers 

5 differential  gauge  calibrated 

6 hose  hydrostatic  test 

7 pressure  regulator  check 

8 pressure  relief  or  pop-off  valve 

9 spark  check ( I AW  TO  00-25-172) 

32  Metera/Counters 

1 auxiliary  engine  houraster 

2 meter/ counters 

3 seals 

k gaskets 

5 O-rlng a 

6 differential  pressure  guage 

7 puap  pressure  guage 

8 single-point  pressure  guage 

9 hydraulic  system  pressure  guage 

33  Tune-Up 

1 minor  - Includes  clean  or  adjust 

points  and  plugs,  set  spark 
timing  and  adjust  carb  idle 

2 major  - includes  renew  and  adjust 

spark  plugs,  renew  points  and 
condenser,  adjust  timing, 
adjust  carb  and  check  vacuum 
advance.  Also,  renew/ check/ 
clean  or  adjust  exhaust 
emission  devices. 

3 spark  plugs/ injectors 
k point  set 

5 condensor 

6 lgnlt lou/injector  timing 

7 cylinder  expression  tast 

8 auxiliary  engine  #1 

9 auxiliary  engine  #2 

3*  Safety  Inspection 

1 see  Section  II,  TO  00-203-5 

2 fork  lift  tine  ln*p(lAW  TO  36K?-2-l-U 

3 fifth  wheel  inap(  I AW  TO  00-203-5) 

k spark  arrestor  check(IAW  TO  3ft- 1-23) 

5 hydraulic  sys  lnsp( I AW  TO  00-203-5) 

6 corrosion  Ctrl  lnap( I AW  TO  36-1-52) 

7 dynamometer  test( I AW  TO  36-1-25) 

8 wheel  bearings  repack ( I AW  TO  00- 20 B- 5 

9 

35  Periodic  Inspection 

1  see  appropriate  vehicle  tech  data 


ATC  - Proposed  System  Codes 


Figure  1 (Cot  eluded) 


36  Oil  Change 

1 prlne  engine 

2 auxiliary  engine  #1 

3 auxiliary  engine  #2 

37  Oil  Filter  Change 

1 prime  engine 

2 auxiliary  engine  #1 

3 auxiliary  engine  |2 

3d  Lubrication 

1  In  accordance  with  manufacturer' s 
recommendations  and  Section  II, 

TO  00-203-5 

39  Body 

1 corrosion  control,  major 

2 corrosion  control,  minor 

3 accident/  abuse  repairs 

k upholstery/soft  trlm/mat a/weather 
molding/ seat s( Includes  seat  adjuster, 
springs  and  frame) 

5 body  and  cab 

6 door /window  handles/knobs/remote 
control  and  regulators 

7 wlndshl eld/door  glsss/resr  glass 

8 tail  gate/bumpers 

9 bedboarda/platforas/stakes 

ko  Other 

1 tire  front/track  left 

2 tire  rear/track  right 

3 fifth  wheel (trk  tractor) 

k towing  devicea( hitches,  pintle 
hooks,  lunettes) 

5 rotating/pulsating  beacon  llght(s) 

6 slren/yelper 

7 spotlight 

8 road  service 

9 tubes /rims 
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Code  'A'  is  used  during  work  order  open,  work  order  amend  or  VDP/OFF 
to  assign  a job.  When  code  'A'  is  used,  the  secondary  action  code 
field  is  blank. 

Code  'D'  is  used  to  specify  that  a job  is  to  be  deferred.  The 
secondary  action  code  field  following  the  slash  is  used  to  indicate 
the  reason  for  deferment.  The  allowable  three-letter  codes  include: 

PER  Personnel  not  available 

DFP  Deferred  for  parts  and  vehicle  returned  to  service 
SKL  Skill  not  available 
KIT  TCTO  awaiting  kit 

EQP  Tools,  equipment  or  facilities  not  available 
PRI  Military  priority  - vehicle  required  for  mission 
FND  Funds  not  available 

ACC  Vehicle  awaiting  investigation  of  accident/abuse 

Code  'S'  is  used  during  the  VDP/ON  transaction  to  designate  a 
job  that  is  being  suspended  (that  is,  the  vehicle  is  retained  in  the 
shop  but  work  on  the  vehicle  is  stopped)  because  necessary  parts  are 
not  available.  When  code  'S'  is  used,  the  secondary  action  code 
field  is  filled  in  as  'VDP'. 

Code  'P'  is  used  at  work  order  completion  time  to  designate  a 
job  that  has  been  completed  and  should  be  posted  to  the  historical 
maintenance  file.  When  code  is  used,  the  secondary  action  code 
field  is  used  to  indicate  the  type  of  maintenance  performed.  The 
allowable  three-letter  codes  include: 

ADJ  Adjusted 
FIX  Repaired 
RPL  Replaced 
SER  Serviced 
OVR  Overhauled/Rebuilt 

Code  'K'  is  used  during  work  order  initiation,  amendment  or 
completion  to  designate  a job  that  is  to  be  killed  or  cancelled. 
When  code  'K'  is  used,  the  secondary  action  code  field  is  blank.  A 
scheduled  [or  deferred]  maintenance  job  that  is  cancelled  with  code 
'K'  is  not  actually  cancelled,  but  is  returned  to  the  scheduled  [or 
deferred]  maintenance  file. 


SITE  CODES 

Data  for  more  than  one  transportation  activity  are  frequently 
processed  by  VIMS  at  a single  base-level  computer  installation. 
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Where  this  occurs,  each  separate  activity  is  assigned  a single 
character  site  code  that  is  used  as  part  of  each  VIMS  transaction  to 
indicate  to  which  site  the  data  relates.  In  the  on-line  VIMS  it  is 
proposed  that  each  transaction  initiated  from  a CRT  terminal  begin 
with  the  site  code,  followed  immediately  by  the  transaction  code. 

For  example,  for  site  code  H the  Work  Order  Open  transaction  would 
be: 


HOPEN 

If  the  base-level  computer  were  only  supporting  a single 
transportation  activity,  the  site  code  would  be  unnecessary. 
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TRANSACTIONS  - WORKLOAD  CONTROL 


Open  Work  Order 

1.  AFTO  Form  37 ^ and  Vehicle  Serv-O-Plate  are  brought  to 
workload  control  to  open  a work  order  for  an  incoming  vehicle. 

2.  The  following  dialog  occurs  at  the  CRT  terminal,  where 
entries  in  parentheses  are  supplied  by  the  operator: 

(ATTENTION  KEY) 

TRANSACTION  ? 

OPEN  Normal  work  order 

OPENA  Accident  repair 

OPENC  Contract  maintenance 

OPENG  Other  government  agency  maintenance 

VEHICLE  ? 

(69B01922)  [Precede  with  'T'  for  transient  vehicle] 

3.  The  record  for  the  designated  vehicle  is  located  in  the 
vehicle  master  file,  and  the  scheduled  maintenance  indicator  is 
checked.  If  any  is  due,  it  is  displayed  as  shown  in  Figure  2. 

4.  The  operator  designates  the  scheduled  maintenance  jobs  he 
wishes  to  assign  by  filling  in  the  selection  indicator  as  follows: 

Y - assign  the  job 

N or  blank  - do  not  assign  the  job 

5.  After  scheduled  maintenance  has  been  taken  care  of,  VIMS 
checks  the  deferred  maintenance  indicator.  If  any  jobs  are  on  file 
for  this  vehicle  including  TCTO  jobs,  they  are  displayed  as  shown  in 
Figure  3* 


6.  The  operator  designates  those  deferred  maintenance  jobs  he 
wishes  to  assign  by  filling  in  the  Selection  Indicator  as  follows: 

Y - assign  the  job 

N or  blank  - do  not  assign  the  job 

7.  After  the  operator  has  designated  the  scheduled  and  deferred 
maintenance  jobs  to  be  assigned  (if  any),  VIMS  will  display  a work 
order  form  in  the  format  of  Figure  4. 

a.  The  work  order  number  is  assigned  by  VIMS. 
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Figure  2.  Scheduled  Maintenance  as  Displayed  During  OPEN 
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Figure  3.  Deferred  Maintenance  as  Displayed  During  OPEN 


WORK  ORDER  NO  (4227)  VEHICLE  REG  NO(69B01922)  DATE  OPENED (74333)  TIME(1343) 
MGT  CODE (8204)  MAKE /TYPE (P-U  CHE)  DATE  COMPLETED ( ) TIME ( ) 
R/D  CODEC  ) MILEAGE  EXCEEDED  ( ) AGE  EXCEEDED  ( ) 
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Figure  4.  Work  Order  as  Initially  Displayed  During  OPEN 


b.  The  vehicle  registration  number  as  supplied  by  the  operator 
is  repeated. 

c.  The  transaction  date  and  time  are  supplied  by  VIMS  from  a 
system  calendar  and  clock.  [These  items  may  be  overwritten 
by  the  operator  if  he  chooses.] 

d.  The  vehicle  management  code,  make/type,  reimbursable/ 
refundable  code  and  one-time  repair  limit  are  accessed  from 
the  vehicle  master  record  and  entered  by  VIMS  onto  the 
display. 

e.  If  the  mileage  or  age  limits  have  been  exceeded,  this 
condition  will  be  displayed.  If  this  occurs,  workload 
control  must  obtain  authorization  from  the  Maintenance 
Control  Officer  to  repair  the  vehicle. 

f.  The  work  order  type  (CONTRACT,  OTHER  GOVT  AGENCY,  ACCIDENT 
or  blank  for  normal)  is  added  by  VIMS  to  the  displayed  work 
order. 

g.  Any  scheduled  maintenance  jobs  selected  by  the  operator  for 
assignment  are  automatically  filled  in  by  VIMS,  including 
the  system  code,  job  description  and  standard  hour 
estimate. 

h.  Any  deferred  maintenance  jobs  selected  by  the  operator  for 
assignment  are  also  filled  in  by  VIMS.  The  system  code, 
work  center,  job  description,  estimated  material  cost  and 
standard  hours  are  supplied  directly  from  the  deferred 
maintenance  file  entry.  For  back-ordered  parts,  the  bin 
location  is  shown  as  part  of  the  job  description. 

i.  For  each  job  entered,  VIMS  uses  an  internal  algorithm  to 
convert  the  standard  hours  to  an  estimation  of  direct  and 
indirect  labor  costs.  These  costs,  together  with  the 
material  costs  given  for  each  job,  are  accumulated  and 
running  totals  are  displayed  by  VIMS  as  job  entries  are 
filled  in.  The  total  estimated  cost  is  used  to  determine 
if  the  one-time  repair  limit  will  be  exceeded.  NOTE:  The 
costs  associated  with  any  jobs  charged  to  operations  are 
not  included  in  this  total. 

8.  The  operator  enters  Priority.  Miles/Hours . User  Phone  and 
Work  Order  Type  (formerly  the  work  order  prefix).  [When  the  operator 
enters  the  current  mileage  it  will  be  compared  internally  with  the 
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estimated  mileage.  If  they  differ  by  more  than  500  miles,  the 
discrepancy  will  be  brought  to  the  operator's  attention.] 

9.  The  operator  enters  jobs  to  be  done  as  noted  on  the  AFTO 
Form  374.  For  each  job,  he  gives  action  code  'A',  the  system  code, 
work  center,  job  description,  estimated  material  cost  (optional), 
and  standard  hour  estimate.  As  the  jobs  are  entered,  VIMS  updates 
the  cumulative  cost  estimate. 

10.  If  a job  is  assigned  with  system  code  17x,  indicating  brake 
repairs,  VIMS  will  check  to  see  if  a safety  inspection  is  due  within 
60  days  or  2000  miles.  If  so,  the  safety  inspection  will  be 
automatically  assigned  as  the  next  job. 

11.  If  more  than  five  jobs  are  to  be  entered,  a function  key 
will  call  up  a second  page.  The  job  itemization  portion  of  the 
display  will  be  overlaid  with  a form  for  jobs  5 - 10.  Another 
function  key  will  return  the  display  to  page  1.  If  any  jobs  are 
entered  on  page  2,  the  'Page  2'  indicator  that  follows  job  5 will  be 
marked  by  VIMS  with  an  X. 

12.  If  at  any  time  the  estimated  cost  of  repair  exceeds  the 
one-time  repair  limit,  a message  to  that  effect  will  appear  on  the 
displayed  work  order.  The  operator  completes  filling  out  the  work 
order  and  upon  completion  of  the  transaction,  VIMS  will  enter  it  in 
the  work  order  file  and  tag  it  as  suspended  awaiting  approval  for 
repair.  A printed  copy  will  be  generated  showing  the  repair  limit 
against  a breakdown  of  estimated  repair  costs.  This  copy  will  be 
forwarded  to  the  proper  authority  for  approval. 

When  a repair  decision  has  been  made,  notification  will  be  made 
to  workload  control,  where  the  following  dialog  will  ensue  at  the 
CRT: 

(ATTENTION  KEY) 

TRANSACTION  ? 

(RESUME  nnnn)  Resume  opening  work  order  nnnn 
[or  (CANCEL  nnnn)  Cancel  work  order  nnnn] 

Assuming  that  authorization  for  repair  was  granted,  RESUME  will 
essentially  pick  up  the  Open  transaction  where  it  left  off. 

13.  The  operator  may  completely  cancel  any  job  on  the  work 
order  by  changing  its  action  code  from  'A'  to  K (scheduled  [and 
deferred]  jobs  will  be  returned  to  their  respective  files). 
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14.  When  all  jobs  have  been  entered,  the  operator  signals  by 
function  key  that  the  work  order  is  complete  and  should  be  cut  as 
shown.  VIMS  will  do  the  following: 

a.  Create  an  entry  in  the  open  work  order  file. 

b.  Update  the  scheduled  maintenance  file  if  necessary. 

c.  Update  the  deferred  maintenance  file  if  necessary. 

d.  Access  the  historical  maintenance  data  for  the  vehicle  and 
check  for  possible  repetitive  maintenance.  For  each  job 
just  assigned,  if  there  are  any  previous  entries  under  the 


same  major 
maintenance 
For  example 

system  code 
history  for 

within  the  past  6 
that  system  code 

months,  the 
will  be  displayed 

System 

Code 

Sub-system 

Code 

Date 

Maintenance 

Action 

16 

1 

73275 

RPL 

16 

7 

74065 

FIX 

16 

3 

74065 

RPL 

The  operator  examines  the  historical  maintenance  data  and 
determines  whether  or  not  any  repetitive  maintenance  may  be 
indicated. 


Wherever  he  feels  it  is  necessary,  he  will  annotate  the 
work  order  to  alert  the  shop  personnel  to  determine  the 
reason  for  the  repeat  maintenance. 

[If  the  operator  chooses,  he  may  get  a copy  of  the 
displayed  historical  maintenance  data  printed  at  the 
terminal  printer.] 

e.  Print  two  copies  of  the  work  order.  The  shop  copy  will  be 
printed  as  shown  in  Figure  5.  The  material  cost  and 
standard  hours  columns  are  replaced  on  the  shop  copy  with  a 
column  for  the  mechanic's  initials  or  employee  number  to  be 
entered.  At  the  bottom  of  the  work  order,  space  is 
provided  for  recording  Quality  Control  inspection  data. 

The  QC  data,  except  for  the  narrative  remarks,  will  be 
entered  into  VIMS  during  work  order  close,  which  may 


29 


fO 


«o 

O 1 

H | 

X 1 

U aj  r\ 

< 1 

2:  X IL. 

X • 

M M ^ 

0 1 

K 1—  Ui 

Ui  1 

X 

X 1 

>- 

0 r\  ft— 

| r> 

1 «“>  * 

( 

( 

c 

( 

c 

c 

X) 

1 

ao 

lO  £K 

1 

«-• 

10  UI 

1 

s 

9 O 

1 

»x  x 

1 

z 

w w 0 

1 

»-« 

0 0 

• 

CO 

Ui  ui 

ft 

ft-  V 

z •-  x 

ft 

«< 

ui  ui  0 

1 

ft- 

CL  -1  X 

ft 

to 

O tL 

ft 

0 

X 

ft 

X 

Ui  O GO 

ft 

X 

H 0^*10 

ft 

Ui 

< rO 

1 

X 

Olii'-'^ 

1 

ft- 

1-  O ft 

ft 

< u ^ 

ft 

•0 

O O N 

1 

CM  Ui  CM 

1 

X 

CM  ui 

ft 

Ui 

X 

Ol  O UI 

1 

CD 

Z) 

^ X z 

ft 

z 

X 

Si  Ui  0 

ft 

9 

CO 

CD  X 

1 

X 

X 

Ui 

Ol  Ui  CL. 

1 

0 

UJ 

:> 

O 

tO  C3 

1 

1- 

-i 

UI 

w <t  x 

Z 1 Ui 

X 

« 

ft— 

0 Ui 

0 ft  (3 

UI 

X 

>► 

CJ 

X to 

»-•  1 z 

f- 

UI 

J 

K 1 < 

-1 

Ui 

Ui 

X 

C3  Ui 

CL  1 X 

M 

CJ 

CJ 

CO 

llJ  X r> 

►H  ft  CJ 

X 

<* 

9 

z 

□CO  r> 

X 1 

-1 

-1 

M 

w lO 

0 1 -1 

_J 

X 

X 

Ui  ZD  O CM 

COtf)  1 M 

M 

UI 

ui 

—I 

J 1 LlJ  CM 

0 Ui  ft  0 

0 

X 

X 

0 

CJ  X O rx 

no  1 

. ^ ..  J V_^  w w «-/  W V->  w 

X 

M Ui  X) 

IUUiS 

V *"> 

r-\  0 

z 

Ui(L 

yC  1 S 

s 

Si 

0 

>>  X CO 

X X ft  CM 

CM 

rO 

lO 

CJ 

1-  UJ  X 

O ft-  ft  CM 

CM 

CM 

CM 

N X 

X O ft 

v-* 

V/ 

>- 

UJ  UJ  N 

ft— 

K if  0 CO 

a 1 ^ 

CM  < C UJ 

x 1 0 

O 

X 

X 

—1 

Oil  U J 

0 ft  ^ 

w# 

w 

w ^ w 

■9 

— ) 

9 _J  •-* 

0 m r 

Ui  ft  ^ 

#-v 

«— % 

X 

50  D ft  ^ 

«-« 

CO 

O M 

> O ft  © 

rv 

0% 

X 

Z Q 

tO  O ft  rO 

10 

® 

(9 

M 

CM  — 

ft  ^ 

w w *--» 

□C  CD  >~ 

UI  ^ 

ao  • 

0 0 « 

— • CM  CM  O lO  M <9101010  M> 

X. 

CJ 

QUJ  li  > 

nz  1 s 

s s 

<9  S 9 S SS  3 9 Si 

ui 

X O O 1- 

ft 

X 

r 1 

O O O •“* 

ft 

w 

U U (T 

Z ui  ft 

^ O 

ft-  O ft 

ai-OH 

uo  1 V 

"V 

XXV 

oi3  \ a 

<U  ft  < 

•< 

«< 

9 

■»  t rv  n 

Q 
Hi 
• — 
CJ 
UJ 

n 

Ui 

X 


30 


Figure  5.  Shop  Copy  of  Work  Order 


eliminate  the  necessity  for  a separate  QC  inspection 
register. 

Amend  Work  Order 


1 .  When  it  becomes  necessary  to  amend  a work  order  to  remove 
or  revise  a job  or  to  add  jobs  that  the  shop  may  have  discovered  are 
necessary,  the  shop  copy  of  the  work  order  is  brought  to  workload 
control. 


2.  The  following  dialog  occurs  at  the  CRT,  where  entries  in 
parentheses  are  supplied  by  the  operator: 

(ATTENTION  KEY) 

TRANSACTION  ? 

(AMEND) 

WORK  ORDER  NUMBER  ? 

(4227) 

3.  As  during  work  order  open,  VIMS  checks  the  scheduled  and 
deferred  maintenance  indicators  for  the  vehicle.  If  they  are  set, 
the  scheduled  and/or  deferred  maintenance  for  the  vehicle  is 
displayed  and  the  operator  is  given  another  opportunity  to  select 
scheduled  or  deferred  jobs  for  assignment. 

4.  The  work  order  is  then  retrieved  from  the  open  work  order 
file  and  displayed,  with  newly  selected  scheduled  or  deferred 
maintenance  jobs,  if  any,  added  to  it. 

5.  The  cumulative  cost  estimates  are  again  shown. 

6.  The  operator  adds,  alters  or  cancels  jobs,  using  the  same 
general  rules  and  procedures  that  pertain  for  work  order  initiation. 
As  this  is  done,  VIMS  continues  to  keep  the  running  tally  of 
estimated  repair  cost. 

7.  When  all  amendment  actions  are  completed,  the  operator 
signals  this  fact  by  function  key.  VIMS  will  do  the  following: 

a.  Update  the  entry  for  this  work  order  in  the  open  work  order 
file. 

b.  Update  the  scheduled  and  deferred  maintenance  files  if  they 
were  affected. 
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c.  For  any  jobs  that  may  have  been  added,  perform  a check  of 
the  historical  maintenance  data  as  was  done  during  work 
order  open,  to  reveal  any  possible  repetitive  maintenance. 

d.  Print  updated  copies  of  the  work  order  (optional). 

Close  Work  Order 


1.  When  all  work  on  a vehicle  is  completed,  the  shop  copy 
of  the  work  order  will  be  returned  to  workload  control  for 
processing. 

2.  The  following  dialog  occurs  at  the  CRT,  where  entries  in 
parentheses  are  supplied  by  the  operator: 

(ATTENTION  KEY) 

TRANSACTION  ? 

(CLOSE) 

WORK  ORDER  NUMBER  ? 

(4227) 

3.  VIMS  will  retrieve  and  display  the  designated  work  order  as 
it  currently  exists  in  the  open  work  order  file.  The  date  and  time  of 
work  order  completion  will  be  automatically  filled  in. 

4.  The  operator  will  review  the  displayed  jobs  and,  using  the 
shop  copy  of  the  work  order  as  reference  will  indicate  to  VIMS  the  dis- 
position of  each  assigned  job  (see  Figure  6) . 

a.  Completed  jobs  will  be  given  the  action  code  to 
indicate  they  should  be  posted  to  the  historical 
maintenance  file.  The  secondary  action  code  field  will  be 
filled  in  with  a three-letter  code,  signifying  the 
maintenance  action  taken  for  the  job. 

ADJ  - adjusted 
FIX  - repaired 
RPL  - replaced 
SER  - serviced 
OVR  - overhauled 

b.  Jobs  that  must  be  deferred  are  given  action  code  'D', 
followed  by  a three-letter  secondary  action  code  indicating 
the  reason  for  deferment. 
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Figure  6.  Work  Order  at  Completion  of  CLOSE 


PER 

DFP 

SKL 

KIT  see  "ACTION  CODES"  at  the  beginning 

EQP  of  this  section  for  explanation  of 

PRI  codes 

FND 

ACC 

VIMS  will  enter  these  jobs  in  the  deferred  maintenance 
file. 

c.  If  the  page  2 indicator  is  on,  the  operator  will  call  up 
the  next  page  of  the  work  order  and  continue  to  enter  the 
disposition  of  jobs. 

5.  Jobs  which  may  have  been  written  in  on  the  shop  copy  of  the 
work  order  but  not  yet  added  to  the  internal  copy  may  be  added  to 
the  display  at  this  time.  Their  disposition  is  entered  as  described 
above. 


6.  After  the  disposition  of  all  jobs  has  been  entered,  the 
operator  enters  Quality  Control  inspection  data  that  may  have  been 
recorded  on  the  shop  copy  of  the  work  order.  If  the  vehicle  was  QC 
inspected,  the  operator  X*s  the  QC  field.  For  each  job  that  failed 
to  pass  QC  inspection,  the  operator  will  enter  the  job  number  and 
mechanic  number.  This  QC  data  will  be  entered  in  the  work  order 
file.  [R&A  will  be  given  a capability  to  initiate  QC  displays  and 
statistical  reports  based  on  this  data.]  The  shop  copy  of  the  work 
order  will  be  forwarded  to  R&A;  they  can  refer  to  this  copy  if  they 
wish  to  read  specific  remarks  by  the  QC  inspector  regarding  rejected 
jobs. 


7.  Once  the  job  disposition  and  QC  data  has  been  entered,  the 
operator  signals  the  end  of  the  transaction  through  the  use  of  a 
function  key.  VIMS  will  do  the  following: 

a.  Completed  jobs  will  be  posted  to  the  historical  maintenance 
record  for  the  vehicle. 

b.  Deferred  jobs  will  be  added  to  the  deferred  maintenance 
file. 


c.  Quality  control  data  will  be  added  to  the  work  order  file. 

d.  The  work  order  will  be  considered  as  completed,  and  VIMS 
will  stop  accumulating  down  time  for  the  vehicle.  The  work 


34 


order  will  be  internally  marked  as  completed  (but  not 
officially  closed)  as  of  the  system-supplied  date  and  time 
of  completion. 

e.  If  jobs  are  deferred  and  the  vehicle  is  returned  to 
service,  a list  of  deferred  jobs  is  printed  to  be  carried 
in  the  vehicle  with  the  operator  inspection  guide.  (See 
Figure  7) . 

f.  The  operator  is  given  the  option  of  obtaining  a printed 
copy  of  the  closed  work  order. 

Display  Status  of  Work  Order  File 

1.  This  transaction  is  provided  to  permit  the  operator  at 
workload  control  to  display  for  review  a summary  of  the  status  of 
all  work  orders  in  the  active  work  order  file. 

2.  The  transaction  is  initiated  as  follows: 

(ATTENTION  KEY) 

TRANSACTION  ? 

(WO/REVIEW) 

3.  VIMS  will  display  page  1 of  the  work  order  file  summary,  as 
shown  in  Figure  8,  and  will  allow  the  operator  to  use  a function  key 
to  step  from  one  page  to  the  next,  forward  or  backward,  through  the 
file. 


4.  The  operator  may  optionally  cause  a printed  copy  of  the 
file  to  be  generated  on  the  terminal  printer. 

5.  The  operator  will  signal  the  end  of  the  transaction  via 
function  key. 

VDP  ON  Procedure 


1 . This  transaction  is  initiated  by  the  operator  at  workload 
control  when  a work  order  is  to  be  suspended  because  a vehicle  has 
been  declared  VDP. 

2.  The  following  dialog  occurs  at  the  CRT,  where  entries  in 
parentheses  are  supplied  by  the  operator: 
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****  WORK  ORDER  FILE  SUMMARY  **** 
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Figure  8.  Work  Order  File  Summary  Display 


(ATTENTION  KEY) 

TRANSACTION  ? 

( VDP/ON) 

WORK  ORDER  NUMBER  ? 

(4364) 

DATE/TIME  ON  VDP  ? 

(74093/0930) 

If  the  operator  does  not  enter  the  DATE/TIME,  VIMS  will  supply  the 
current  date  and  time. 

3.  VIMS  will  retrieve  and  display  the  designated  work  order, 
adding  to  the  display  the  VDP  status,  date  and  time. 

4.  The  operator  will  indicate  the  VDP  jobs  by  changing  their 
action  code  to  S/VDP. 

5.  When  the  operator  signals  completion  of  the  transaction, 
VIMS  will: 

a.  Switch  the  accumulating  down  time  for  the  vehicle  from  VDM 
to  VDP. 

b.  Enter  all  VDP  jobs  in  the  deferred  maintenance  file. 

c.  Place  the  work  order  in  open-suspended  status. 

VDP  OFF  Procedure 


1.  This  transaction  is  initiated  by  the  operator  at  workload 
control  when  he  wishes  to  reactivate  a suspended  work  order  and 
remove  the  vehicle  from  VDP  status. 

2.  The  following  dialog  occurs  at  the  CRT  where  entries  in 
parentheses  are  supplied  by  the  operator: 

(ATTENTION  KEY) 

TRANSACTION  ? 

(VDP/OFF) 

WORK  ORDER  NUMBER  ? 

(4364) 

DATE/TIME  OFF  VDP  ? 

(74096/1345) 

As  in  VDP  ON,  if  the  operator  does  not  enter  a date  and  time,  the 
current  date  and  time  will  be  supplied  by  VIMS. 
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3.  VIMS  will  retrieve  and  display  the  work  order. 

4.  The  action  code  for  any  VDP  jobs  will  be  changed  from 
'S/VDP'  to  'A',  and  the  jobs  will  be  removed  from  the  deferred 
maintenance  file. 

5.  VIMS  will  switch  the  accumulating  down  time  for  the  vehicle 
from  VDP  to  VDM. 

6.  Once  the  work  order  has  been  returned  to  open-active 
status,  the  operator  may  enter  additional  jobs  as  during  work  order 
amendment. 

Add  Job  to  Deferred  Maintenance  File 


1.  This  transaction  is  provided  to  allow  workload  control  to 
add  jobs  to  the  deferred  maintenance  file  directly,  without 
operating  through  a work  order-related  transaction.  It  is  intended 
specifically  for  the  case  where  deferred  maintenance  for  a vehicle 
is  to  be  recorded  although  the  vehicle  was  not  accepted  into  the 
shop,  and  hence  had  no  work  order  opened  against  it. 

2.  The  dialog  at  the  CHT  for  this  transaction  is: 

(ATTENTION  KEY) 

TRANSACTION  ? 

(DEFEH/ADD) 

VEHICLE  ? 

(65C01819) 

3.  VIMS  will  display  a form  as  shown  in  Figure  9»  The 
deferred  maintenance  file  will  be  searched,  and  any  jobs  that  are 
deferred  for  this  vehicle  will  be  displayed. 

4.  VIMS  begins  a new  entry  by  supplying  the  date  and  assigning 
a dummy  work  order  number  (XXXX)  and  a job  number.  The  operator 
completes  the  entry  according  to  the  format  in  Figure  9.  As  each 
entry  is  completed,  VIMS  will  begin  the  next,  inserting  work  order 
number  XXXX  and  assigning  the  next  sequential  job  number. 

5.  When  all  jobs  have  been  added,  the  operator  terminates  the 
transaction  with  a function  key. 

6.  VIMS  adds  the  job(s)  to  the  deferred  maintenance  file  and 
sets  tne  deferred  maintenance  indicator  in  the  vehicle  master 
record.  If  any  added  jobs  are  given  a deferral  code  of  DFP 
(deferred  for  parts),  a message  to  materiel  control  is  printed, 
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identifying  the  new  deferred  jobs  requiring  parts  (see  Figure  10). 

A printed  copy  of  all  deferred  jobs  for  this  vehicle  is  also 
prepared,  to  be  carried  in  the  vehicle. 

Change  Job  in  Deferred  Maintenance  File 

1.  This  transaction  is  provided  to  allow  workload  control  to 
make  changes  or  corrections  to  entries  in  the  deferred  maintenance 
file. 

2.  The  dialog  at  the  CRT  for  this  transaction  is: 

(ATTENTION  KEY) 

TRANSACTION  ? 

(DEFER/CHANGE) 

VEHICLE  ? 

(69B01922) 

3.  VIMS  displays  all  deferred  jobs  for  the  specified  vehicle, 
using  the  format  of  Figure  3. 

4.  The  operator  enters  a 'C'  under  SEL  IND  for  each  entry  to 
be  changed,  and  then  alters  items  in  the  entry  as  necessary. 

5.  When  all  changes  have  been  entered,  the  transaction  is 
terminated  by  function  key  and  VIMS  makes  the  indicated  changes  to 
the  file. 

Delete  Job  from  Deferred  Maintenance  File 

1.  This  transaction  is  provided  to  allow  workload  control  to 
remove  jobs  from  the  deferred  maintenance  file. 

2.  The  dialog  at  the  CRT  for  this  transaction  is: 

(ATTENTION  KEY) 

TRANSACTION  ? 

(DEFER/DELETE) 

VEHICLE  ? 

(69B01922) 

3.  VIMS  displays  all  deferred  jobs  for  the  specified  vehicle, 
using  the  format  of  Figure  3» 

4.  The  operator  enters  a D'  under  SEL  IND  for  each  entry  to 
be  deleted. 
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NEW  DEFERRED  job9  REQUIRING  PARTS  * 
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Figure  10.  Parts  Request  Generated  by  DEFER/ ADD 


5.  When  all  deletions  have  been  indicated,  the  transaction  is 
terminated  by  function  key. 

6.  VIMS  deletes  the  designated  jobs  from  the  deferred 
maintenance  file.  If  all  deferred  jobs  for  the  vehicle  have  been 
deleted,  the  deferred  maintenance  indicator  in  the  vehicle  master 
record  is  turned  off. 

[TCTO  Procedure] 

1 . When  workload  control  receives  a TCTO  order  it  will  be 
time/date  stamped,  and  the  operator  at  workload  control  will 
initiate  the  following  VIMS  transaction  at  the  CRT: 

(ATTENTION  KEY) 

TRANSACTION  ? 

(TCTO) 

TCTO  NUMBER  ? 

(nn n) 

COMPLIANCE  TIME  ? 

(30  DAYS) 

2.  VIMS  will  display  a form  as  shown  in  Figure  11. 

3.  The  operator  will  enter  the  FSN , Management  Code  and  year 

for  the  affected  vehicles  from  the  TCTO,  and  VIMS  will  scan  the 
vehicle  master  file  to  determine  if  the  TCTO  applies  to  any  vehicles 
in  the  fleet.  If  so,  their  vehicle  registration  numbers  will  be 
displayed.  The  operator  may  alternatively  enter  the  vehicle 
registration  numbers  directly  if  they  are  known.  NOTE:  Other  search 
keys  may  be  required,  to  determine  if  the  TCTO  applies  to  any 
vehicles  in  the  fleet. 

4.  Assuming  the  TCTO  does  apply,  VIMS  will  display  a form  as 

shown  in  Figure  12,  which,  when  completed,  represents  the  entry  to 

be  made  in  the  deferred  maintenance  file  for  each  affected  vehicle. 

5.  The  operator  completes  the  TCTO  deferred  job  entry,  and 
VIMS  adds  it  to  the  deferred  maintenance  file  for  each  vehicle  to 
which  the  TCTO  pertains. 

6.  VIMS  prints  two  copies  of  the  transaction,  showing  the 
vehicles  to  which  the  TCTO  applies.  One  copy  will  be  used  by 
workload  control  in  scheduling  vehicles  into  the  shop.  The  other 
copy  will  be  forwarded  to  materiel  control  to  serve  as  a parts 
request  if  the  TCTO  requires  parts  (as  TCTO  parts  or  kits  are 
prepared  or  received,  materiel  control  will  enter  their  bin 


43 


c 


c 

a 

c 


§ 

o 

H 

U 

H 


si 

mi 

><i 


Ml 
H Ql 
O Ol 
£ Ol 


• I 

W Ol 
P S5I 

o 

M • I 
M Ol 
W Ml 
> Ml 


03 

4J 

CTJ 

Q 

P 

O 

M 

CTJ 

0) 

C/3 

O 

H 

O 

H 


U 

u 

c 

w 


l-l 

o 


B 

u 

o 


0) 

3) 


Pm 


44 


eCOI 

Wl 
go  wi 


I 


HI 
CO  I 
Ol 
Ul 


CO 

I 

CO 


Ol 


21 

1 

♦ 

Ol 

1 

•1C 

Ml 

1 

•K 

HI 

d 

■K 

Wl 

3 

Ml 

d 

CQ 

W 1 

O 

Ol 

• 

•o 

CO  1 

o 

Wl 

2 

Q 

QI 

1 

O 

3 

Wl 

H 

Ol 

O 

W 

Ol 

H 

E 

w 

Q 

O 

| E! 

H 

5 oi 

O 

H 

* 

W Wl 

O 

* 

W QI 

U 

* 

Q Ol 

H 

•IC 

o 

W 

>N 

u 

C 

w 

o 

»-) 

X) 

0) 

M 

CD 

M-l 

CD 

Q 

o 

H 

O 

H 


CO  Wl 
H QI 
CO  Ol 


CO  *1 
O Ol 
*->  21 


CNJ 


0) 

l-l 

d 

60 


W Wl 

52  qi 
o oil 
:*  oi 


o 

H 

O 

H 


E! 

£1 


co 

On 


45 


l 


locations  in  the  deferred  file  entries,  using  the  DEFER/CHANGE 
transaction) . 
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TRANSACTIONS  - MATERIEL  CONTROL 


Review  Back-Ordered  Parts  Status 

1.  This  transaction  allows  materiel  control  to  display  and 
page  through  the  Back-Ordered  Farts  file  (BOPF)  in  order  to  review 
the  status  of  any  items  in  the  file. 

2.  The  transaction  is  initiated  as  follows: 

(ATTENTION  KEY) 

TRANSACTION  ? 

(PARTS/REVIEW) 

3.  VIMS  will  display  page  1 of  the  BOPF,  and  will  allow  the 
operator  to  use  a function  key  to  step  from  one  page  to  the  next, 
forward  or  backward,  through  the  file.  Items  will  be  displayed  as 
in  Figure  13.  [The  operator  may  optionally  cause  a printed  copy  of 
the  file  to  be  generated  on  the  terminal  printer.] 

4.  The  operator  will  signal  the  end  of  the  transaction  via 
function  key. 

Add  Item  to  Back-Ordered  Parts  File 

1.  This  transaction  will  allow  materiel  control  to  add  new 
items  to  the  BOPF. 

2.  The  transaction  is  inititated  as  follows: 

(ATTENTION  KEY) 

TRANSACTION  ? 

(PARTS/ADD) 

VEHICLE  ? 

(69B01922) 

3.  VIMS  will  retrieve  and  display  all  entries  in  the  BOPF  (if 
any)  for  the  specified  vehicle. 

4.  VIMS  will  start  a new  entry  by  filling  in  the  Vehicle 
Registration  Number.  The  operator  will  complete  the  entry  according 
to  the  format  shown  in  Figure  14.  As  each  entry  is  completed,  VIMS 
will  begin  the  next  by  inserting  the  Vehicle  Registration  Number. 

5.  When  all  additions  for  the  specified  vehicle  have  been 
entered,  the  operator  terminates  the  transaction  via  function  key, 
and  VIMS  updates  the  BOPF. 
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***BACK  ORDERED  PARTS*** 
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Figure  13.  Page  of  Back-Ordered  Parts  File  as  Displayed  by  PARTS/REVIEW 
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Figure  14.  Displayed  Form 


Change  Item  in  Back-Ordered  Parts  File 


1.  This  transaction  will  allow  materiel  control  to  change  or 
update  an  existing  entry  in  the  BOPF  (e.g.  report  availability  and 
bin  location  of  received  part). 

2.  The  transaction  is  initiated  as  follows: 

(ATTENTION  KEY) 

TRANSACTION  ? 

(PARTS/CHANGE) 

VEHICLE,  A( ALL) , OR  X(EXIT) 

3.  The  operator  is  given  three  options: 

a.  If  he  knows  the  vehicle  for  which  the  parts  were  ordered 
(he  can  determine  this  from  a printout  of  the  BOPF),  he 
simply  enters  the  Vehicle  Registration  Number.  VIMS  will 
locate  and  display  all  back-ordered  parts  for  the 
designated  vehicle,  as  shown  in  Figure  15. 

b.  If  the  operator  enters  an  'A',  VIMS  will  display  page  1 of 
BOPF  and  the  operator  will  be  allowed  to  page  through  the 
file  as  in  PARTS/REVIEW  until  he  locates  the  entries  to  be 
changed. 

c.  If  the  operator  enters  an  'X',  VIMS  will  exit  from  the 
transaction. 

4.  Once  the  operator  locates  an  entry  to  be  changed,  he  steps 
the  cursor  to  the  beginning  of  that  entry,  and  enters  a 'C' 
preceding  the  Vehicle  Registration  Number.  He  then  makes  whatever 
changes  or  additions  to  the  line  that  are  necessary. 

5.  The  process  is  repeated  for  each  entry  to  be  changed. 

6.  When  all  changes  have  been  entered,  the  operator  terminates 
the  transaction  via  function  key. 

7.  VIMS  will  update  the  BOPF  to  reflect  the  changes  entered. 

If  the  transaction  reported  the  receipt  of  parts  already  on  order, 
VIMS  will  check  to  see  if  all  parts  for  the  specific  job  are  now  on 
hand.  If  they  are,  the  corresponding  entry  in  the  deferred 
maintenance  file  will  be  internally  updated  to  show  the  bin  location 
of  the  parts. 
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8.  In  the  latter  case,  a PARTS  ARRIVAL  NOTIFICATION  (see 
Figure  16)  will  be  printed  at  workload  control,  indicating  the  fact 
that  a deferred  job  may  now  be  done.  Special  attention  will  be 
drawn  to  VDP  jobs  for  which  parts  are  now  available. 

Delete  Item  from  Back-Ordered  Parts  File 

1.  This  transaction  will  allow  materiel  control  to  remove 
items  from  the  BOPF. 

2.  The  transaction  is  initiated  as  follows: 

(ATTENTION  KEY) 

TRANSACTION  ? 

(PARTS/DELETE) 

VEHICLE,  A( ALL)  OR  X(EXIT) 

3.  The  operator  is  given  three  options: 

a.  If  he  knows  the  vehicle  for  which  the  parts  were  ordered  he 
simply  enters  the  Vehicle  Registration  Number.  VIMS  will 
locate  and  display  all  back-ordered  parts  for  the 
designated  vehicle,  as  shown  in  Figure  15. 

b.  If  the  operator  enters  an  'A',  VIMS  will  display  page  1 of 
BOPF  and  the  operator  will  be  allowed  to  page  through  the 
file  as  in  PARTS/REVIEW  until  he  locates  the  entries  to  be 
deleted. 

c.  If  the  operator  enters  an  ’X’,  VIMS  will  exit  from  the 
transaction. 

4.  Once  the  operator  locates  an  entry  to  be  deleted,  he  steps 

the  cursor  to  the  beginning  of  that  entry  and  enters  a D . 

5.  When  all  deletions  have  been  indicated,  the  operator  will 

terminate  the  transaction  via  function  key,  and  VIMS  will  delete  the 
indicated  items  from  the  BOPF. 

Report  Issue  of  Back-Ordered  Parts 

1.  This  transaction  will  be  initiated  by  materiel  control  when 
a back-ordered  part  is  finally  issued  against  a work  order  for 
installation  on  a vehicle.  The  part  will  usually,  but  not  neces- 
sarily, be  issued  to  the  vehicle  for  which  it  was  ordered.  The 
purpose  of  this  transaction  is  to  remove  the  part  from  the  BOPF,  and 
to  charge  the  cost  of  the  part  to  the  proper  vehicle.  The  cost  of 
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Figure  16.  Parts  Arrival  Notification 


all  back-ordered  parts  is  carried  temporarily  in  account  H8888  until 
it  can  be  applied  to  a specific  vehicle. 

2.  The  transaction  is  inititated  as  follows: 

(ATTENTION  KEY) 

TRANSACTION  ? 

(PA RTS/ ISSUE) 

WORK  ORDER  NO.  ISSUED  AGAINST  ? 

(4227) 

3.  VIMS  will  display  page  1 of  the  BOPF,  and  will  allow  the 
operator  to  use  a function  key  to  step  from  one  page  to  the  next 
through  the  file. 

4.  The  operator  will  locate  the  issued  part(s)  on  the  CRT  and 
will  check  them  off  by  entering  an  'X'  at  the  beginning  of  each  line 
entry  (See  Figure  17). 

5.  When  all  parts  issued  against  the  specified  work  order  have 
been  X'd,  the  operator  will  signal  completion  via  function  key. 

6.  VIMS  will 

a.  [Subtract  the  cost  of  the  specified  part(s)  from  account 
H8888  and  charge  it  to  the  designated  work  order.] 

b.  [When  adding  the  charge  to  the  work  order  record,  check  to 
see  if  the  vehicle  to  which  the  part  was  issued  is  the 
vehicle  for  which  it  was  ordered.  If  not,  check  the 
deferred  maintenance  file  and  make  sure  that  the  original 
job  for  which  the  part  was  ordered  no  longer  shows  the  part 
as  available. ] 

c.  Remove  the  issued  part(s)  from  the  BOPF. 

Review  High  Cost  Bench  Stock  Master  File 

1.  This  transaction  will  allow  an  operator  in  materiel  control 
to  review  the  contents  of  the  HCBS  master  file. 

2.  The  transaction  is  initiated  by  the  operator  at  the  CRT  as 
follows : 


(ATTENTION  KEY) 
TRANSACTION  ? 
(HCBS/REVIEW) 
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Figure  17.  Display  During  PARTS/ISSUE 


3.  VIMS  will  display  page  1 of  the  HCBS  master  file  in  the 
format  of  Figure  18  and  will  allow  the  operator  to  use  a function 
key  to  step  from  one  page  to  the  next,  forward  or  backward,  through 
the  file.  [The  operator  will  be  permitted  optionally  tc  obtain  a 
printed  copy  of  the  file  on  the  terminal  printer.] 

4.  The  operator  will  signal  the  completion  of  the  transaction 
via  function  key. 

Add  Item  to  High  Cost  Bench  Stock  Master  File 

1,  This  transaction  takes  the  place  of  the  E transaction  in 
the  present  system,  and  will  be  used  by  an  operator  in  materiel 
control  for  adding  new  items  to  the  HCBS  master  file. 

2.  The  transaction  will  be  initiated  by  an  operator  at  the  CRT 
as  follows: 


(ATTENTION  KEY) 

TRANSACTION  ? 

(HCBS/ADD) 

3.  VIMS  will  present  a form  on  the  CRT  in  the  format  shown  in 
Figure  19.  The  operator  will  enter  one  or  more  items  on  the  form, 
supplying  FSN,  price,  EEIC  code,  charge  code  and  description  for 
each.  The  operator  also  specifies  how  many  Q cards  are  to  be 
generated  for  each  new  stock  item.  VIMS  will  assign  a 3-digit  item 
number  to  each  added  item. 

4.  After  the  operator  has  completed  making  entries,  he  signals 
the  completion  of  the  transaction  via  function  key.  VIMS  will: 

a.  Update  the  HCBS  master  file. 

b.  [Cause  the  requested  number  of  Q cards  to  be  generated,  to 
be  delivered  to  materiel  control.] 

Change  High  Cost  Bench  Stock  Master  File  Entry 

1.  This  transaction  will  allow  an  operator  in  materiel  control 
to  make  changes  to  existing  items  in  the  HCBS  master  file. 

2.  The  transaction  is  initiated  by  the  operator  at  the  CRT  as 
follows : 
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Figure  19.  Displayed  Form  for  Adding  Item  to  HCBS  File 


(ATTENTION  KEY) 

TRANSACTION  ? 

(HC BS/CHANGE) 

ITEM  NUMBER  ? 

(043) 

3.  VIMS  will  locate  the  requested  item  in  the  HCBS  file  and 
will  display  it  in  the  format  shown  in  Figure  20. 

4.  The  operator  will  make  any  desired  changes  to  the  displayed 
entry. 

5.  When  changes  are  complete,  the  operator  signals  this  fact 
to  VIMS,  and  VIMS  will  return  the  corrected  entry  to  the  HCBS  file. 

Delete  High  Cost  Bench  Stock  Master  File  Entry 

1.  This  transaction  will  allow  an  operator  in  materiel  control 
to  remove  entries  from  the  HCBS  master  file. 

2.  The  transaction  will  be  initiated  by  the  operator  at  the 
CRT  as  follows: 

(ATTENTION  KEY) 

TRANSACTION  ? 

(HCBS/DELETE) 

ITEM  NUMBER  ? 

(013) 

3.  VIMS  will  locate  the  specified  item  and  remove  it  from  the 
HCBS  file. 

Issue  High  Cost  Bench  Stock  Item 


1.  This  transaction  will  be  used  by  an  operator  in  materiel 
control  to  cause  VIMS  to  charge  a HCBS  item  to  the  work  order 
against  which  it  was  issued. 

2.  When  a HCBS  part  is  issued,  the  issuing  agent  completes  a Q 
card  for  that  item  giving  the  date,  quantity  issued  and  work  order 
number.  If  he  wishes  to  replenish  his  stock  of  Q cards  for  this 
item,  he  also  enters  a replenishment  quantity. 

3.  Completed  Q cards  will  be  delivered  to  materiel  control, 
where  an  operator  at  the  CRT  will  initiate  a transaction  as  follows: 


59 


I 

I u 

I M 
I K 
I < 
I £ 
I D 
I lU 
I Z 
Z I CL 
O I • 

H | U 
H I ID 

a.  i 3 

H » h 

o:  i cr 

U I LU 
CD  1 Z 
UJ  I Z 

Oli-4 


UJ  I 

O I 

O I 

O I 

I o 

+ O I 

* XI 

+ U I 

OJ 

-I  U I O) 

M H | s 

U-  UJ  I <o 

UJ  I 

u 

O UJ  f 

H-  O I 

<D  M | 

a i ^ 

X Q.  I 3 

«-J  I • 

Z I—  I 

UJ  H | *4 

ID  ZB 

3 I 

I- 

CD 

0 I 

L»  I 

I 

X • 

L3  I 

m i in 

X I ^ 

• o> 

♦ I «H 

1 I 40 

• I S' 

I 5) 

Z I — • 

to  I <o 

U.  I CM 


• B 

a b 

Z I 
I 

X B 

UJ  I to 
H I ^ 
H K Q 


60 


Figure  20.  Item  Displayed  for  HCBS/CHANGE 


(ATTENTION  KEY) 

TRANSACTION  ? 

( HCBS/ISSUE) 

4.  VIMS  will  display  a form  as  shown  in  Figure  21. 

5.  The  operator  will  fill  in  the  form,  one  item  per  line. 

When  all  issued  items  have  been  entered,  the  operator  will  signal 
completion  of  the  transaction  via  function  key. 

6.  For  each  entry,  VIMS  will: 

a.  [Use  the  item  number  to  locate  the  HCBS  master  file  record 
for  the  part  and  obtain  the  FSN,  the  unit  cost  and  charge 
code. ] 

b.  [Use  the  data  retrieved  from  the  HCBS  record  together  with 
data  from  the  ISSUE  transaction  to  make  an  entry  in  the 
designated  work  order  record  that  charges  the  cost  of  the 
HCBS  part(s)  to  the  proper  work  order.] 

c.  [Subtract  the  corresponding  cost  from  account  H8888,  to 
which  all  HCBS  parts  are  charged  until  issued.] 

d.  [Cause  the  requested  number  of  Q cards  to  be  generated  for 
subsequent  delivery  to  materiel  control  if  replenishment  is 
indicated  on  an  ISSUE  entry.] 

[VDP  Summary  Display] 

1 . This  transaction  when  initiated  will  result  in  a CRT 
display  showing  the  status  of  parts  for  all  vehicles  that  are 
currently  VDP.  The  display,  which  is  a composite  of  items  from  the 
deferred  maintenance  file  and  the  back-ordered  parts  file,  is 
intended  to  replace  the  VDP  status  board  in  materiel  control. 

2.  The  transaction  is  initiated  as  follows: 

(ATTENTION  KEY) 

TRANSACTION  ? 

( VDP/DISPLAY ) 

3.  VIMS  searches  the  deferred  maintenance  file,  locating  all 
VDP  jobs  and  noting  the  time  and  date  that  VDP  was  declared. 

4.  The  corresponding  entry  is  located  in  the  back-ordered 
parts  file,  from  which  VIMS  obtains  information  on  parts  status. 
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5.  A display  is  generated,  using  the  format  shown  in  Figure 

22. 

6.  If  the  operator  desires,  he  may  cause  a copy  of  the  VDP 
Summary  Display  to  be  printed  on  the  terminal  printer. 

Input  COPARS  Cost  Data 

1 . This  transaction  will  be  used  by  an  operator  in  materiel 
control  to  enter  cost  data  into  VIMS  for  parts  issued  from  COPARS. 
The  same  transaction  will  be  used  to  help  the  operator  keep  track  of 
parts  warranty  information. 

2.  The  transaction  will  be  initiated  at  the  CRT  as  follows: 

(ATTENTION  KEY) 

TRANSACTION  ? 

(COPARS) 

DATE  ? 

(74335) 

WORK  ORDER  NUMBER  ? 

(4217) 

3.  VIMS  will  determine  which  vehicle  is  represented  by  the 
designated  work  order,  and  will  scan  a parts  warranty  file  to 
determine  if  there  are  any  part  warranties  still  in  effect  for  this 
vehicle.  If  there  are,  they  will  be  displayed  as  shown  in  Figure 
23.  The  operator  can  then  check  the  sales  slip  against  the  display 
to  see  if  a part  under  warranty  is  being  replaced. 

4.  After  the  operator  has  reviewed  the  warranty  display  (if 
any),  he  signals  PROCEED  with  a function  key,  and  VIMS  displays  a 
form  as  shown  in  Figure  24  for  sales  slip  data  input  (if  no  warranty 
data  was  found  for  this  vehicle,  the  sales  slip  input  form  will  be 
displayed  automatically). 

5.  For  each  entry  on  the  sales  slip  the  operator  will  input 
the  part  number,  quantity,  unit  list  price  and  the  percentage 
discount  to  be  applied.  VIMS  will  compute  and  display  the  cost  for 
each  entry  (discounted  unit  cost  times  quantity). 

6.  If  the  part  was  received  in  fulfillment  of  a back  order, 
the  BOP  indicator  is  X'd. 

7.  If  the  part  carried  a special  warranty,  the  warranty 
indicator  is  X'd  and  the  duration  of  the  warranty  in  days  and  miles 
is  entered. 
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Figure  22.  VDP  Summary  Display 
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Figure  23.  Parts  Warranty  Display 


****  COPARS  SALES  SLIP  ENTRY  **** 
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Figure  24.  COPARS  Sales  Slip  Data  Entry  Form 


8.  The  part  description  is  entered.  This  entry  is  optional 
except  for  parts  under  warranty. 

9.  The  operator  will  signal  when  the  last  part  has  been 
entered,  at  which  time  VIMS  will: 

a.  Compute  and  display  a total  cost  for  the  sales  slip. 

b.  [Update  the  work  order  file  with  cost  data  for  all 
installed  parts.] 

c.  [Charge  the  cost  of  back-ordered  parts  received  to  account 
H8888  (when  they  are  subsequently  issued  to  a specific 
vehicle,  the  cost  will  be  transferred  from  account  H8888  to 
the  vehicle. ) ] 

d.  Log  the  transaction  onto  a file  that  will  be  later  passed 
to  Accounting  & Finance. 

e.  For  each  part  that  carried  a special  warranty,  make  an 
entry  in  the  parts  warranty  file.  Entries  will  include: 

Vehicle  Registration  Number 

Part  Number 

Part  Description 

Date  Installed 

Mileage  When  Installed 

Warranty  Period 

Warranty  Miles 
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TRANSACTIONS  - REPORTS  AND  ANALYSIS  (R&A) 

[Update  Scheduled  Maintenance] 

1.  This  transaction  allows  R&A  to  update  the  scheduled 
maintenance  data  for  a vehicle  when  such  maintenance  is  reported  on 
AF  Form  15  or  SF  Form  149.  This  replaces  the  use  of  N cards  for 
reporting  scheduled  maintenance  when  no  work  order  has  been  opened. 

2.  The  transaction  is  initiated  as  follows: 

(ATTENTION  KEY) 

TRANSACTION  ? 

(SCHED/UPDATE) 

VEHICLE  ? 

(67B00243) 

3.  VIMS  will  present  a form  on  the  CRT  as  shown  in  Figure  25. 

4.  The  operator  will  fill  in  the  form  and  signal  completion 
via  function  key. 

5.  VIMS  will  update  the  vehicle  master  record  for  the 
designated  vehicle. 

T Update  Historical  Repair  File] 

1.  This  transaction  will  allow  R&A  to  enter  into  the  vehicle 
historical  repair  file  a record  of  any  maintenance  performed  on  a 
vehicle  that  was  not  reported  on  a work  order  (e.g.,  emergency  road 
repairs) . 

2.  The  operator  will  initiate  the  transaction  as  follows: 

(ATTENTION  KEY) 

TRANSACTION  ? 

(HIST/UPDATE) 

VEHICLE  ? 

(67B00243) 

3.  VIMS  will  display  a form  as  shown  in  Figure  26. 

4.  The  operator  will  enter  the  maintenance  history  data, 
making  one  entry  for  each  system/subsystem  repaired.  The 
"Maintenance  Action"  entry  will  be  one  of  the  following: 
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Figure  25.  Scheduled  Maintenance  Update  Form 
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ADJ  - adjusted 
FIX  - repaired 
RPL  - replaced 
SER  - serviced 
OVR  - overhauled/rebuilt 

5.  When  all  data  has  been  entered,  the  operator  will  terminate 
the  transaction  and  VIMS  will  add  the  new  data  to  the  historical 
repair  file  for  the  designated  vehicle. 

[Update  Parts  Warranty  File] 

1.  This  transaction  will  allow  an  operator  in  R&A  to  record 
any  special  warranties  for  parts  installed  on  a vehicle  but  not 
reported  in  the  usual  way  (e.g.  repairs  reported  on  AF  Form  15  or  SF 
Form  149). 

2.  The  transaction  will  be  initiated  at  the  CRT  as  follows: 

(ATTENTION  KEY) 

TRANSACTION  ? 

(WARRANTY/UPDATE) 

VEHICLE  ? 

(69D00818) 

3.  VIMS  will  scan  the  parts  warranty  file  and  will  display  any 
warranties  currently  in  effect  for  the  designated  vehicle.  These 
will  be  presented  on  the  display  in  the  format  of  Figure  23. 

4.  The  operator  will  enter  the  data  necessary  to  define  the 
new  warranty. 

5.  When  all  data  has  been  entered,  the  operator  will  terminate 
the  transaction  and  VIMS  will  add  the  new  item  to  the  parts  warranty 
file. 

Fuel/Oil  Issue  Transaction 


1.  This  transaction  will  be  used  by  R&A  to  report  fuel  and  oil 
issue  data  to  VIMS.  Sources  for  this  data  will  be  copies  of  AF  Form 
1251  initiated  daily  by  the  base  service  station,  and  all  fuel  and 
oil  sales  as  reported  on  AF  Form  15  and  SF  Form  149. 

2.  Normal  mode  will  be  to  input  fuel/oil  issue  data  in  a 
batch.  This  batch  input  corresponds  to  the  preparation  and 
submission  of  M cards  in  the  present  system. 
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3.  The  operator  will  initiate  the  transaction  as  follows: 

(ATTENTION  KEY) 

TRANSACTION  ? 

(FUEL) 

4.  VIMS  will  display  a form  as  shown  in  Figure  27. 

5.  The  operator  will  enter  data  on  the  displayed  form  as 
illustrated.  As  each  line  is  completed  it  will  be  validity  checked. 
Any  errors  will  be  noted  at  the  end  of  the  line  entry.  The 
following  error  messages  may  appear: 

a.  UNRECOGNIZED  VEHICLE.  The  Vehicle  Registration  Number  does 
not  correspond  to  any  in  the  fleet. 

b.  INVALID  FUEL  ENTRY.  This  message  is  given  whenever  a fuel 
quantity  greater  than  30  gallons  is  entered. 

c.  INVALID  OIL  ENTRY.  This  message  is  given  whenever  an  oil 
quantity  greater  than  2 quarts  is  entered. 

d.  INVALID  DATE.  The  date  entered  is  greater  than  today's 
date. 

6.  If  an  entry  contains  an  error,  the  operator  has  three 
immediate  options: 

a.  Correct  the  entry. 

b.  Cancel  the  entry  (set  aside  the  source  document  for 
resolution  and  later  entry). 

c.  Ignore  (override)  the  error  and  proceed. 

7.  When  the  screen  is  filled,  VIMS  will  save  the  data  and 
clear  the  screen  for  additional  entries. 

8.  When  all  data  has  been  entered  the  operator  signals  via 
function  key  [and  VIMS  uses  the  data  to  update  the  vehicle  master 
file. ] 

Manhour  Reporting 

1.  This  transaction  will  be  initiated  by  an  operator  in  R&A  in 
order  to  enter  into  VIMS  the  data  from  employee  labor  time  cards. 
Time  cards  will  be  completed  daily  by  each  employee  and  delivered  to 
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****  FUEL/OIL  ISSUE  **** 


ISSUING  ORG 

VEHICLE 
REG.  NO. 

FUEL 

(GAL) 

OIL 

(QT) 

DATE 

OM 

68B09355 

18.5 

74325 

CM 

71B01762 

15.0 

74325 

OM 

73B027^5 

11.6 

74325 

OM 

67B03306 

36.8 

74325 

INVALID  FUEL  ENTRY 

OM 

67B06193 

13.4 

74325 

OM 

67B06193 

1 

74325 

OM 

67B06193 

19.1 

74326 

OM 

69  B0 1922 

3 

74325 

INVALID  OIL  ENTRY 

Figure  27.  Displayed  Form  for  Fuel/Oil  Issue  Data  Entry 
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R&A,  where  they  will  normally  be  entered  into  VIMS  in  batches  by 
work  center. 

2.  The  transaction  will  be  initiated  as  follows: 

(ATTENTION  KEY) 

TRANSACTION  ? 

(TIME/INPUT) 

WORK  CENTER,  SSAN,  OR  X(EXIT) 

(17220)  batch  input  for  work  center 

or  (036366930)  separate  input  for  one  employee 

3.  If  the  operator  wishes  to  enter  the  data  for  a single 
employee,  he  gives  the  employee's  SSAN.  VIMS  will  obtain  the  name 
and  assigned  work  center  and  will  display  these  together  with  the 
SSAN  on  an  input  form  as  shown  in  Figure  28.  The  operator  enters 
data  from  the  time  card  and  signals  via  function  key  when  he  is 
done.  VIMS  will  accept  the  data,  and  will  again  prompt  with 

WORK  CENTER,  SSAN,  OR  X(EXIT) 

4.  If  the  operator  wishes  to  enter  data  in  a batch  for  a work 
center,  he  gives  a work  center  number.  VIMS  will  then  present,  one 
at  a time,  the  names  of  all  employees  assigned  to  that  work  center. 
The  names  will  be  obtained  from  the  employee  master  file  in 
alphabetic  order,  and  will  be  presented  as  follows: 

NEXT  EMPLOYEE  IS  ASHER  N K 

N (NEXT)  S(SKIP)  P(PREVIOUS)  X(EXIT) 

The  operator  has  the  following  options: 

a.  If  the  operator  has  a time  card  matching  the  name  shown,  he 
enters  'N'  for  NEXT  and  a form  for  data  input  (see  Figure 
28)  will  be  displayed.  The  operator  enters  the  data  from 
the  time  card  and  signals  via  function  key  when  he  is  done. 
VIMS  will  accept  the  data  for  the  employee,  and  will  prompt 
by  showing  the  next  name  from  the  work  center: 

NEXT  EMPLOYEE  IS  BACON  H P 

N(NEXT)  S(SKIP)  P( PREVIOUS)  X(EXIT) 

b.  If  the  operator  has  no  data  for  the  employee  shown,  he 
enters  'S'  meaning  SKIP,  and  VIMS  will  prompt  by  showing 
the  next  name  alphabetically  from  the  work  center  list. 
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Figure  28.  Displayed  Form  for  TIME/ INPUT 


c.  If  the  operator  wishes  to  enter  a card  out  of  sequence  he 
enters  'P ' , and  VIMS  asks  for  the  employee's  SSAN.  The 
operator  enters  the  SSAN  and  VIMS  displays  an  input  form 
with  the  employee's  name,  SSAN  and  assigned  work  center 
filled  in.  The  operator  enters  the  data  for  the  employee 
and  signals  via  function  key  when  he  is  done.  VIMS  accepts 
the  data,  and  returns  to  the  alphabetic  sequence 
temporarily  broken,  prompting  with  the  next  name  from  the 
work  center  list. 

d.  The  operator  may  terminate  the  prompting  by  name  for  a work 
center  by  entering  'X'  for  EXIT.  VIMS  will  assume  that  he 
has  no  more  data  for  the  work  center,  and  will  allow  him  to 
select  another  work  center,  prompting  with 

WORK  CENTER,  SSAN,  OR  X(EXIT) 

NOTE:  This  will  happen  automatically  after  all  employees 

from  a work  center  have  been  processed. 

5.  When  no  more  data  is  to  be  entered,  the  operator  responds 
to  the  prompt 

WORK  CENTER,  SSAN,  OR  X(EXIT) 


with  an  'X'. 

6.  VIMS  will  perform  a number  of  validity  checks  on  the  data. 

A check  is  made  to  see  if  8 hours  of  prime  shift  time  have  been 
reported  by  each  employee,  and  to  verify  that  all  work  order  numbers 
and  job  numbers  reported  are  legitimate.  If  no  errors  are  found,  an 
employee's  time  is  accepted  as  reported. 

7.  For  those  records  that  fail  the  validity  checking,  VIMS 
will  create  an  error  suspense  file  and  will  print  an  error  listing 
(see  Figure  29)  showing  the  data  as  it  was  reported  and  flagging  all 
detected  errors. 

8.  After  determining  what  corrections  are  necessary,  the 
operator  will  accomplish  them  using  the  TIME/EDIT  transaction. 

Error  Correction  for  Manhour  Reporting 

1.  During  the  TIME/INPUT  transaction,  any  time  card  entries 
that  fail  the  validity  checking  are  saved  on  an  Error  Suspense  File 
(ESF).  The  operator  is  provided  with  a printout  of  the  ESF,  showing 
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the  data  as  reported  and  with  all  detected  errors  flagged.  Each 
entry  on  the  ESF  is  assigned  an  entry  number  (see  Figure  29). 

2.  The  operator  determines  the  corrections  to  be  made,  and 
initiates  the  error-correction  transaction  as  follows: 

(ATTENTION  KEY) 

TRANSACTION  ? 

(TIME/EDIT) 

ENTRY  OR  X(EXIT) 

(001) 

3.  As  shown  above,  the  operator  gives  the  number  of  the  entry 
he  wishes  to  correct.  VIMS  retrieves  the  entry  from  the  ESF  and 
displays  it  in  the  same  format  used  for  TIME/INPUT. 

4.  The  operator  makes  any  desired  corrections  and  signals 
completion  via  function  key. 

5.  The  entry  is  immediately  checked  for  errors.  If  none  are 
found,  the  entry  is  accepted  and  the  message 

ENTRY  IS  NOW  CORRECT 

will  appear.  If  the  entry  still  contains  errors,  the  newest  version 
will  replace  the  previous  version  on  the  ESF  (same  entry  number)  and 
the  operator  will  be  informed 

ENTRY  IS  STILL  INCORRECT 

In  either  case,  VIMS  will  again  prompt  with 

ENTRY  OR  X(EXIT) 

6.  The  operator  continues  to  make  corrections  to  whatever 
entries  he  may  choose.  When  he  is  done,  he  terminates  the 
transaction  by  entering  ^X/.  If  any  entries  remain  uncorrected,  the 
ESF  will  be  preserved,  and  the  operator  will  be  given  an  option  to 
print  a new  copy  of  the  ESF. 
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SECTION  V 


COMMENTS  DURING  TESTING  (SUMMARIZED  AND  ANNOTATED) 


DISCUSSION 

The  material  in  this  section  represents  a summarization  and 
categorization  of  comments  that  were  recorded  during  testing.  A 
total  of  almost  400  comments  were  recorded  by  the  two  observers. 

The  comments  were  numbered,  sorted  and  categorized,  primarily  by  the 
transaction  to  which  they  pertained.  They  were  further  sorted  by 
sub-category  within  transaction.  A separate  category  was  created 
for  comments  regarding  the  CRT  keyboard,  for  requests  and 
suggestions  regarding  special  reports  and  inquiries,  and,  of  course, 
the  inevitable  General  category  for  those  comments  that  didn't  fit 
anywhere  else. 

After  sorting,  comments  were  combined  and  summarized.  Many  of 
the  comments  were  repeats,  either  because  both  observers  had 
recorded  the  same  comment,  or  because  different  subjects  or  teams 
said  essentially  the  same  thing.  Where  necessary,  comments  were 
annotated  to  further  clarify  or  illustrate  the  intent.  Due  to  the 
lack  of  time  and  the  volume  of  feedback,  there  has  not  been  an 
opportunity  to  examine  or  analyze  the  comments  in  any  depth. 

Given  the  transactional  descriptions  in  Section  IV  as  a 
baseline,  the  comments  should  provide  strong  guidance  to  subsequent 
iterations  of  transactional  specifications.  It  is  urged,  however, 
that  this  not  be  done  too  precipitously.  The  comments  reveal  that 
there  are  some  major  changes  to  be  considered,  and  these  should  be 
addressed  and  thought  out  carefully.  Major  modifications  should  be 
validated  if  possible  by  discussion  with  functional  personnel.  This 
is  especially  true  in  the  materiel  control  area. 


COMMENTS 
1 . OPEN 

a.  Repetitive  Maintenance 

1.  Six  months  seems  a reasonable  cut-off  point  for  keeping 
repair  history  for  repeat  maintenance  checking. 

2.  The  repeat  maintenance  file  entry  should  include  the 
mileage  at  which  each  maintenance  action  was  taken. 
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3.  "I  think  the  expanded  system  codes  will  be  sufficient  to 
identify  repeat  maintenance.” 

4.  "When  making  job  changes  to  the  work  order  we  will  not 
forget  to  look  at  repeat  maintenance  - it  will  always  be  there 
automatically. " 

5.  There  are  two  criteria  to  be  considered  in  repeat 
maintenance. 

(1)  For  major  components  we  must  talk  about  periods  of  up 
to  a year 

(2)  On  minor  components  we  only  look  for  90-180  days. 

6.  Could  repeat  maintenance  and  warranty  be  tied  together? 

7.  The  repeat  maintenance  display  should  be  titled,  more  self- 
explanatory,  and  should  print  out  somewhere  rather  than  requiring 
the  operator  to  copy  or  hand  annotate  the  work  order. 

8.  Repeat  maintenance  would  be  easier  to  identify  if  the  file 
entries  contained  the  original  job  descriptions. 

9.  The  work  order  number  would  be  useful  data  to  include  as 
part  of  the  Historical  Repair  File. 

10.  When  possible  repeat  maintenance  is  displayed,  there  is  no 
way  to  compare  it  against  the  jobs  just  assigned,  since  the  work 
order  has  been  removed  from  the  display  but  not  yet  printed. 

Suggestion:  Automatically  print  possible  repeat  maintenance  on  the 

work  order. 

Suggestion:  When  creating  the  work  order,  check  as  each  job  is 

assigned  and  show  possible  repeat  maintenance 
immediately  on  the  bottom  of  the  screen.  The  operator 
can  then  annotate  the  job  on  the  screen  if  he  feels 
that  it  is  true  repeat  maintenance. 


b.  One-Time  Repair  (OTR) 

1 . Model  is  OK  in  allowing  OTR-exceeded  condition  to  be 
removed  by  killing  jobs.  There  may  be  legitimate  reasons  for  doing 
this. 
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2.  We  need  an  automated  system  to  come  in  and  change  our 
records  to  keep  one-time  repair  allowances  correct.  This  is  a pain 
in  the  neck. 

3.  Mileage  Exceeded  and  Age  Exceeded  condition  need  not  be 
shown  on  the  work  order  unless  the  OTR  limit  is  exceeded. 

NOTE:  This  remark  was  from  Hanscom.  SAC  disagreed,  saying 
that  they  must  always  get  special  repair  approval  if 
Miles,  Age  or  OTR  is  exceeded. 

4.  Work  order  should  show  when  OTR-limit  is  permanently 
exceeded  (replacement  code  A-D).  If  it  is,  the  work  order  should  be 
automatically  OTR-suspended  at  DONE. 

5.  If  OTR-limit  is  exceeded,  print  this  fact  on  the  shop  copy 
as  well  as  workload  control's  copy  of  the  work  order. 

6.  When  OTR-limit  is  exceeded,  print  only  approval  copy. 

Print  shop  copy  only  on  RESUME.  Less  chance  of  shop  doing  the  job 
before  approval. 

c . Scheduled  Maintenance 

1.  If  scheduled  maintenance  is  due,  the  display  should  specify 
whether  the  criteria  met  was  MILES,  TIME,  or  both. 

2.  We  should  be  able  to  see  when  last  oil  change,  safety, 
scheduled  inspection,  etc.  was  performed  - have  no  visibility  now. 


3.  A Scheduled  Inspection  is  required  every  4 months  or  4000 
miles.  The  model  does  not  include  any  Scheduled  Inspections. 

4.  A Safety  Inspection,  required  every  12  months  or  12,000 
miles,  incorporates  everything  done  normally  in  a Scheduled 
Inspection,  and  should  therefore  update  the  Scheduled  Inspection  due 
date  (current  VIMS  complains  if  a Safety  Inspection  is  reported 
before  3 Scheduled  Inspections  are  reported). 

5.  "We  won't  be  able  to  overlook  scheduled  or  deferred 
maintenance  any  more." 

6.  LUBRICATION  should  be  charged  to  M not  0. 

7.  Need  to  use  actual  mileage  entered  during  OPEN  to  check  if 
scheduled  maintenance  is  due.  The  Scheduled  Maintenance  indicator 
in  VMF  gets  set  based  on  estimated  mileage  computed  from  fuel 
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consumption.  Actual  mileage  may  show  that  scheduled  maintenance  is 
due  even  though  the  indicator  was  not  set. 

NOTE:  It  may  be  necessary  to  input  latest  mileage  as  part 

of  the  calling  sequence  in  order  for  VIMS  to  take  it  into 
account  before  presenting  the  Scheduled  Maintenance 
display. 

8.  In  the  case  of  Accident  Repair  or  any  other  case  where 
scheduled  or  deferred  maintenance  cannot  be  included,  annotate  the 
work  order  if  scheduled  or  deferred  actions  are  due.  This  will  help 
to  insure  that  they  will  be  caught  before  the  vehicle  is  released. 

d . Deferred  Maintenance 


1.  "We  will  not  be  able  to  overlook  deferred  maintenance  any 
more. " 

2.  When  a job  that  was  assigned  to  the  work  order  from  the 
deferred  maintenance  file  is  killed,  it  should  be  automatically 
returned  to  the  DMF. 

NOTE:  This  was  in  the  specs  for  the  model 

but  did  not  get  implemented. 


e.  Mileage 

1.  When  vehicle  mileage  is  input  during  OPEN,  it  should  be 
checked  immediately  against  mileage  in  file.  Any  unusual 
discrepancy  (e.g.  difference  greater  than  500  miles)  should  be 
immediately  reported  to  controller.  This  will  allow  him  to  recheck 
the  reading  from  the  vehicle  and  will  help  in  early  detection  of 
erroneous  mileage  inputs,  broken  speedometers,  etc. 

NOTE:  This  was  one  of  the  most  frequent  comments  made  during 

testing.  Apparently  the  introduction  of  erroneous  mileage  for  a 
vehicle  is  a source  of  many  troubles  with  today's  VIMS.  If  it 
is  not  caught  it  can  foul  up  the  scheduled  maintenance 
calculations,  the  updating  of  the  vehicles  miles/gal.  and  the 
replacement  code,  to  name  a few.  All  agreed  that  it  was  very 
important  to  insure  that  the  correct  mileage  was  being  input. 

2.  As  mentioned  previously,  it  was  suggested  that  the  vehicle 
mileage  be  input  during  the  calling  sequence  to  OPEN,  so  that  VIMS 
could  use  it  in  dynamically  calculating  whether  or  not  Scheduled 
Maintenance  is  due  based  on  miles. 
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f . Work  Order  Format 


1 . Printed  work  orders  should  carry  a heading  or  title  to 
identify  which  is  workload  control's  copy  and  which  is  the  shop 
copy. 

2.  The  shop  copy  of  the  work  order  should  show: 

Engine  displacement  (cubic  in.) 

No.  of  cylinders 

Body  type/model 

T.O.  reference 

This  information  would  help  the  mechanic  or  materiel  control  to 
obtain  parts.  This  data  would  have  to  be  added  to  the  vehicle 
master  record. 

3.  There  should  be  no  limit  to  the  number  of  jobs  allowed  on  a 
work  order.  More  than  10  is  common  in  the  experience  of  at  least 
one  group.  Could  easily  go  more  than  20  when  performing  a detailed 
LTI  (Limited  Technical  Inspection). 

4.  If  a work  order  is  suspended  due  to  Age,  Mileage  or  OTR- 
limit  exceeded,  print  on  the  bottom  of  the  work  order  a message  to 
the  effect: 

SIGNATURE  REQUIRED  - OTR-Limit(or  AGE  or  MILES)  Exceeded. 

5.  Assigned  Org.  code  for  the  vehicle  would  be  useful  on  the 
work  order. 

6.  On  larger  bases,  may  need  to  use  five  digits  for  work  order 
number  to  avoid  wrapping  around  too  soon.  Otherwise  it  is  possible 
to  catch  up  and  pass  an  old  deferred  job. 

7.  The  material  cost  item  on  the  work  order  job  entry  should 
be  4 digits  long.  It  may  exceed  $1000  for  a single  job. 

8.  The  R/D  code  does  not  seem  necessary  on  the  work  order. 

9.  One  group  suggested  leaving  5 extra  job  spaces  on  the  work 
order  for  writing  in  new  jobs.  Another  group  thought  that  2 was 
plenty.  The  workload  controller  said  he  wouldn't  want  mechanics 
writing  in  more  than  two  jobs  without  coming  to  him  for  approval 
first. 
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10.  The  shop  copy  of  the  work  order  should  include  space  for 
detailed  parts  request  data. 

NOTE:  TAC  uses  TAC  Form  305,  Parts  Request;  SAC  uses  the 

work  order  itself. 

11.  One  subject  had  difficulty  in  matching  material  cost  and 
standard  hours  items  with  proper  job  numbers  when  looking  at  printed 
copy  of  work  order.  May  want  to  experiment  with  format  changes  for 
legibility. 


g.  Warranty 

1.  Assuming  a Parts  warranty  File,  any  parts  warranties 
currently  in  effect  for  a vehicle  should  be  displayed  and/or  printed 
on  the  shop  copy  of  the  work  order.  It  will  then  be  visible  when 
the  mechanic  goes  to  get  parts. 

2.  After  the  current  mileage  is  entered,  VIMS  should  check  to 
see  if  total  vehicle  warranty  is  still  in  effect  and  should  notify 
operator.  This  would  alert  workload  control  so  decision  could  be 
made  whether  repair  actions  are  covered.  (Total  vehicle  warranty  is 
currently  noted  on  the  margin  of  AFTO  Form  271's  at  Hanscom) . 


h.  Accident 

1 . The  accident  estimate  work  order  should  have  extra  job 
space  enough  to  write  in  all  repairs. 

NOTE:  Another  group  said  an  LTI  is  performed  for  accident 

repairs,  and  the  LTI  form  is  used  to  detail  the  repairs. 

2.  Indirect  costs  are  not  charged  to  an  accident. 

3.  The  model  will  handle  accident  repair  in  close  parallel  to 
today's  manual  procedure,  but  somewhat  awkwardly.  During  testing, 
the  TAC  group  handled  accident  repair  as  follows: 

a.  Opened  a work  order  with  estimating  job  only. 

b.  After  repairs  were  itemized  by  inspector,  amended  the  work 
order  to  add  the  repair  jobs. 

c.  Printed  the  amended  copy,  to  be  sent  for  approval. 
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d.  Closed  the  work  order,  posting  the  estimating  job  as 
complete,  and  aeferring  the  repair  jobs  with  code  D/ACC. 

e.  After  approval,  opened  a new  work  order  for  the  vehicle  and 
accepted  the  deferred  jobs  (used  OPENA  for  this  work 
order) . 

4,  It  was  suggested  that  the  model  be  modified  to  handle 
accident  repairs  in  the  following  manner: 

a.  Open  a type  3 (Special  Inspection!  work  order  for  the 
repair  estimate  only. 

b.  The  inspector  itemizes  repairs. 

o.  Close  the  estimating  job  work  order. 

d.  Open  an  accident-type  work  order  (using  OPENA)  and  itemize 
the  repair  jobs.  VIMS  should  properly  compute  estimated 
costs. 

e.  At  DONE,  work  order  should  be  ACC-suspended  awaiting  repair 
approval . 

f.  Print  copy  as  in  OTfl-limit  exceeded,  and  send  cut  for 
approval. 

g.  Or.  approval,  re-activate  with  RESUME.  If  net  approved, 
scrub  with  CANCEL. 

5.  The  accident  repair  work  order  may  require  4 or  more 


6.  Per  ACCIDENT  work  order,  the  WORK  ORDER  TYPE  could  be 
automatically  filled  in  as  (F). 

7.  For  an  accident  work  order,  it  should  be  more  prominently 
identified  as  ACCIDENT. 


i . Suspend 

1.  In  addition  to  OTh-limit  exceeded,  need  to  be  able  to 
suspend  work  orders  while  awaiting  disposition  of  vehicle,  accident 
or  aouse  investigations,  or  approval  to  repair  wnen  age  and/or 
mileage  is  exceeded. 
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2.  Suspended  work  orders  should  be  clearly  identified  as  such, 
together  with  the  reason  for  suspension.  If  repair  approval  is 
required,  the  printed  copy  should  indicate  that  a signature  is 
required  and  leave  a signature  block. 


j ,  Miscellaneous 


1 . Would  like  to  have  some  record  of  jobs  that  the  QC 
inspector  (incoming  inspection)  had  to  add  to  the  374  that  the 
vehicle  operator  should  have  reported  himself.  These  could  be  noted 
on  the  work  order  during  OPEN  (perhaps  with  an  asterisk  in  the 
secondary  action  code  field  which  will  otherwise  normally  be  blank). 


k.  Implementation 

1 . Workload  control  may  need  to  override  the  Management  Code 
as  entered  on  the  work  order  from  the  Vehicle  Master  record. 

NOTE:  Controller  should  probably  be  allowed  to  override 

any  data  in  the  work  order  header  (including  system- 
supplied  Date/Time). 

2.  Should  be  able  to  return  to  the  header  portion  of  the  work 
order  after  completing  the  variable  entries,  to  make  any  desired 
changes. 


NOTE:  Through  an  oversight,  the  model  does  not  allow 

operator  to  return  to  the  header  portion  of  the  work  order 
once  he  has  begun  to  fill  in  the  jobs. 

3.  Assignment  of  Date  and  Time  by  the  system  met  with  general 
approval,  but  most  felt  that  an  override  capbility  was  essential. 

NOTE:  This  feature  was  specified  but  not  implemented  in 

the  model. 

4.  When  paging  forward  to  continue  adding  jobs  to  the 
displayed  work  order,  repeat  the  last  job  from  the  previous  page  as 
the  first  job  of  the  new  page,  to  help  operator  keep  track  of  where 
he  is  in  case  he  gets  distracted. 

5.  Once  jobs  have  been  accepted  from  the  Scheduled  and 
Deferred  Maintenance  files  for  inclusion  on  the  work  order,  it 
should  not  be  necessary  to  re-accept  them  on  the  work  order. 
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6.  Several  people  felt  it  would  be  more  consistent  to  accept 
Scheduled  and  Deferred  jobs  with  an  'A'  rather  than  a 'Y'. 

7.  Once  a 'Line  Accept'  for  a job  is  given,  software  should 
right- justify  all  numeric  fields,  especially  the  material  cost  and 
standard  hours  items. 

8.  Should  allow  vehicle  registration  numbers  to  be  input  with 
leading  zeroes  omitted  (e.g.  71B00444  or  71B444). 

9.  It  seemed  unnatural  to  use  'Line  Accept'  to  step  from  the 
header  block  to  the  job  assignment  block  of  the  work  order.  May 
want  to  use  TAB  instead. 

10.  Estimated  costs  should  be  updated  even  though  the  work 
center  is  left  blank  (the  model  currently  does  not  calculate  cost 
unless  the  work  center  is  given,  since  the  cost  is  based  on  an 
average  hourly  wage  for  the  specific  work  center). 

11.  Could  software  look  up  the  primary  system  codes  (first  2 
digits)  as  entered  and  fill  in  the  text  equivalent  in  the  job 
description?  E.g.,  a system  code  of  17x  would  result  in  "BRAKES" 
being  automatically  inserted  in  the  job  description. 

12.  When  action  code  'A'  is  used  to  assign  a job,  software 
could  automatically  tab  over  the  rest  of  the  action  code  field  since 
it  is  always  blank  for  primary  code  A. 

13.  When  Line  Accept  is  given  after  assigning  the  last  job  on 
the  displayed  page,  the  cursor  is  returned  to  the  beginning  of  the 
job  instead  of  stepping  down.  Suggest  that  the  cursor  be  stepped 
down  to  the  Next  Page  field,  as  an  indication  that  the  last  job  was 
accepted  and  that  a Forward  Page  is  required  in  order  to  continue 
assigning  jobs. 


2 . AMEND 
a.  Procedure 


1 . Suggest  that  when  a work  order  is  amended  and  a new  copy  is 
printed,  Workload  Control  throw  away  their  old  copy,  but  staple  new 
shop  copy  to  the  old  one. 

NOTE:  The  mechanic(s)  may  already  have  annotated  the  shop 

copy  with  mechanic  number  after  completed  jobs  and  with 
their  own  tally  of  hours  spent  dn  partially  completed  jobs. 


87 


This  suggestion  was  made  in  recognition  of  the  necessity 
for  a procedure  that  will  avoid  requiring  the  mechanic  to 
copy  over  all  of  his  notes  if  an  AMEND  results  in  a new 
shop  copy  of  the  work  order. 

2.  Workload  Control  should  not  add  jobs  to  a work  order  with 
AMEND  without  checking  the  shop  copy  first  to  see  if  the  mechanic 
has  written  in  any  jobs  not  yet  cleared  through  workload  control. 
Otherwise,  may  end  up  with  conflicting  job  numbers. 

b.  Format 


1.  An  amended  work  order  should  show  that  it  has  been  amended, 
and  should  give  the  Date/Time  of  amendment. 


c .  Added  Features 


1 . Should  be  able  to  AMEND  a work  order  while  it  is  still  on 
VDP  without  having  to  take  it  off  VDP  first.  Suggest  using  a 
special  call  for  this  transaction,  such  as  AMEND/VDP. 


d .  Implementation 


1.  If  there  is  more  than  one  display  "page"  to  the  work  order: 
when  stepping  the  cursor  from  job  to  job,  after  the  last  job  on  the 
page,  step  the  cursor  to  the  Page  2 indicator  and  blink  it.  If  the 
last  job  on  the  page  is  amended,  after  the  Line  Accept  is  given, 
step  the  cursor  to  the  Page  2 indicator  and  blink  it. 

2.  When  Action  Code  'K'  is  used  to  kill  or  cancel  a job  during 
AMEND,  the  job  is  erased  and  subsequent  jobs  are  moved  up  to  close 
the  gap.  This  is  OK  during  OPEN,  but  during  AMEND  the  job  should  be 
erased  but  the  gap  should  not  be  closed.  Mechanics  may  have  already 
worked  on  subsequent  jobs  and  may  have  charged  time  against  them, 
and  therefore  they  should  not  be  renumbered.  Suggest  that  the  job 
space  for  the  erased  job  be  filled  with  x's  so  that  it  will  not  be 
re-used,  since  it  is  possible  that  some  time  was  charged  against 
that  job  before  it  was  erased.  Alternatively,  may  want  to  leave  the 
job  on  the  work  order,  but  clearly  mark  it  as  void. 

3.  During  AMEND,  the  checking  for  repetitive  maintenance 
should  be  limited  to  either  added  jobs  or  jobs  where  the  system  code 
was  changed. 
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4.  After  Line  Accept,  software  should  right  justify  numeric 
fields. 

5.  During  AMEND,  should  be  able  to  return  to  the  header 
portion  of  the  work  order  to  change  Priority,  Work  Order  Type,  etc. 

6.  Instead  of  waiting  for  the  WORK  ORDER?  prompt  during  the 
call  to  AMEND,  would  prefer  to  enter  the  work  order  number  as  part 
of  the  initial  call,  e.g. 

AMEND  4226 


3.  CLOSE 
a . Printouts 


1 . We  need  a copy  of  the  closed  work  order  to  give  to  the 
Navy,  Army,  etc.  when  repairs  are  made  on  their  vehicles.  They  need 
it  for  their  records. 

2.  The  printout  of  deferred  maintenance  to  be  carried  in  the 
vehicle  should  be  titled,  e.g.  "Vehicle  Operator's  List  of  Deferred 
Maintenance." 

3.  Any  time  a job  is  deferred  for  parts,  print  the  NEW 
DEFERRED  JOBS  REQUIRING  PARTS  notice  to  materiel  control  (the  model 
only  does  this  for  DEFER/ADD).  Materiel  control  will  use  this 
notice  when  ordering  parts,  and  it  can  be  used  as  their  source 
document  for  the  PARTS/ADD  transaction. 


b . QC  Inspection 

1 . One  group  reported  that  the  union  had  made  them  discontinue 
the  practice  of  tabulating  QC-rejected  jobs  by  actual  mechanics  who 
worked  on  those  jobs. 

2.  A QC  inspection  constitutes  a job  on  the  work  order,  and 
should  be  recorded  as  such. 

NOTE:  This  was  not  the  case  for  all  bases  represented.  If 

the  inspection  is.  considered  a job  on  the  work  order,  the 
QC  inspector  should  simply  write  the  job  in,  using  the  next 
available  job  number,  and  use  this  work  order/ job  number 
when  reporting  his  time  on  his  time  card.  Workload 
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control  can  add  the  QC  inspection  job  to  the  work  order  at 
the  time  it  is  being  closed  out. 


c .  Implementation 

1.  Need  to  be  able  to  override  the  system-supplied  date  and 
time  of  completion. 

2.  If  there  is  more  than  one  page  to  the  displayed  work  order, 
after  entering  the  disposition  of  the  last  job  on  the  page  the 
cursor  should  step  to  the  Page  2 indicator  and  blink  it,  as  a 
reminder  to  the  operator  that  there  are  more  jobs  to  be  processed. 


d .  Procedure 


1.  According  to  current  procedure,  the  Action  Taken  Code  is 
circled  by  shop  personnel  before  the  work  order  is  returned  to 
workload  control  to  be  closed  out.  The  way  the  model  is 
implemented,  the  person  in  workload  control  is  determining  the 
Action  Taken  Code  at  the  time  he  is  closing  the  work  order.  May 
want  to  return  to  the  circled  code  technique,  since  the  shop  knows 
best  what  action  was  actually  taken. 


e .  Added  Features 


1 . A problem  mentioned  by  several  people  was  the  fact  that  in 
the  present  system  a work  order  may  fail  to  close  because  jobs  were 
reported  as  done  but  no  time  is  ever  charged  against  them.  One 
suggestion  was  to  input  the  mechanic(s)  number  for  each  job 
completed  as  part  of  the  CLOSE  transaction.  This  could  be  used  in 
conjunction  with  labor  card  data  to  cross  check,  to  insure  that  a 
mechanic  actually  reports  time  against  all  jobs  he  says  he  worked 
on. 


2.  If  the  operator  at  workload  control  overrides  the  system- 
supplied  date/time  and  assigns  his  own  date/time  to  the  CLOSE,  the 
actual  transaction  time  as  well  as  the  operator-supplied  time  should 
be  recorded  as  a check  against  time  fudging  (if  the  CLOSE  time  were 
frequently  earlier  than  the  wall  clock  time,  it  could  indicate  time 
fudging  to  reduce  VOC  time) . 

3.  Workload  control  will  need  a REOPEN  transaction  for  a 
closed  work  order,  if  it  was  erroneously  closed. 
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f . General 


1.  It  is  helpful  that  the  system  allows  additional  jobs  to  be 
entered  on  CLOSE.  This  may  occur  fairly  often  in  real  life. 
Relatively  minor  jobs  are  often  written  in  by  mechanics  but  not 
brought  back  to  workload  control  for  approval  before  accomplishing. 


4.  RESUME 
a . Implementation 

1.  When  a resume  action  is  taken,  the  date/time  opened  on  the 
work  order  must  be  updated  to  the  date  and  time  of  the  resume 
action.  Otherwise  the  work  order  appears  to  have  been  opened  at  the 
time  it  was  suspended. 


5.  WO/REVIEW 
a.  Content 


1 . Entries  in  the  Work  Order  Status  display  should  indicate  if 
the  work  order  is  an  Accident,  Abuse,  Contract  or  Other  Government 
Agency  type. 

2.  This  display  should  identify  work  orders  open  an  excessive 
amount  of  time. 

3.  A suspended  work  order  should  show  the  reason  for 
suspension  (e.g.,  SUSPENDED  - OTR  or  SUSPENDED  - ACC) 

4.  May  want  to  show  scheduled  maintenance  actions  in  house  (by 
work  center)  as  part  of  the  Work  Order  Status  display.  This  would 
help  to  determine  work  center  loading  when  deciding  whether  or  not 
to  accept  scheduled  maintenance  jobs  during  work  order  initiation. 


b.  Implementation 


1 . Should  be  able  to  page  from  back  to  front  of  the  work  order 
file  on  the  display  as  well  as  front  to  back.  This  would  make  it 
easier  (faster)  to  review  most  recently  opened  work  orders. 
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c.  Forma t/Sequence 


1 . In  addition  to  reviewing  the  file  in  work  order  number  or 
chronologic  sequence,  it  would  be  useful  to  have  the  file  presented 
in  alternative  sequences.  For  example,  present  work  orders  in  the 
following  order: 

OPEN 

VDP 

SUSPENDED  (OTHER  THAN  VDP) 

CLOSED 

2.  On  the  WORK  ORDER  FILE  SUMMARY,  the  item  labeled  W/0  TYPE 
is  not  the  former  prefix  code;  it  is  intended  to  show  Accident, 
Other  Gov't.  Agency  or  Contract  Maintenance  work  orders.  This 
heading  is  confusing  since  the  Work  Order  Type  item  on  the  work 
order  does  refer  to  what  used  to  be  the  prefix  code. 


6.  VDP/ON 

a .  Date/Time 


1.  Should  be  able  to  override  the  system-supplied  date  and 
time  for  VDP/ON,  but  there  should  be  some  check  against  possible 
misuse  of  the  option.  It  was  suggested  that  the  operator  be 
required  to  include  an  explanatory  code  every  time  he  elects  to 
override  the  system  date/time,  and  that  VIMS  keep  a log  of  these. 


b.  Implementation 

1 . When  designating  a job  as  VDP,  the  program  could 
automatically  fill  in  the  secondary  action  code  field  with  VDP  as 
soon  as  the  operator  enters  the  action  code  'S'. 


c .  Added  Feature 


1.  Need  a VDP/REVIEW  transaction  to  allow  review  of  a VDP- 
suspended  work  order  without  removing  it  from  VDP  status. 
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7.  VD P/OFF 


a . Date/ time 


1.  As  with  VDP/ON,  the  operator  should  be  able  to  override  the 
system-supplied  date  and  time  for  VDP  removal,  with  the  suggested 
requirement  that  the  operator  be  required  to  include  an  explanatory 
code  whenever  he  elects  to  override. 

2.  If  the  operator  is  allowed  to  supply  his  own  times  for 
VDP/ON  and  VDP/OFF,  the  system  should  check  to  insure  that  the 
vehicle  never  gets  charged  with  VDP  twice  for  the  same  time.  In 
particular,  if  a vehicle  is  taken  off  VDP  and  then  put  back  on,  make 
sure  that  the  times  run  consecutively  and  don't  overlap. 

3.  The  date  and  time  of  VDP  removal  should  be  properly 
identified  on  the  displayed  work  order  as  OFF  VDP  (the  model 
identifies  it  as  COMPLETED,  which  is  intended  to  designate  the  time 
that  the  work  order  is  closed). 


b . Automatic  VDP/OFF 

1 . When  a PARTS/CHANGE  shows  that  all  necessary  parts  have 
arrived  for  a VDP  vehicle,  the  vehicle  should  automatically  be 
removed  from  VDP  status.  The  time  off  of  VDP  should  be  the  actual 
date/time  of  part  arrival.  The  PARTS  ARRIVAL  NOTIFICATION  to 
workload  control  should  show  the  vehicle  as  being  removed  from  VDP, 
the  date  and  time  that  it  was  taken  off  of  VDP,  and  should  give  the 
number  of  the  open  work  order. 


8.  DEFER/ADD 
a.  General 

1.  Many  people  voiced  concern  because  the  DEFER/ADD  results  in 
a deferred  job  without  a work  order  number  (the  model  assigns  dummy 
work  order  number  XXXX).  Most  said  that  a work  order  number  was 
necessary  to  order  parts. 

NOTE:  A procedures  change  is  required  that  would  allow 

parts  to  be  ordered  directly  against  a vehicle.  When  jobs 
are  deferred  for  parts  with  DEFER/ADD,  the  NEW  DEFERRED 
JOBS  REQUIRING  PARTS  notice  that  is  printed  out  can  serve 
as  proof  that  the  parts  are  being  ordered  legitimately 
against  the  vehicle. 
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b.  Parts  Requirement  Notice 


1.  The  NEW  DEFERRED  JOBS  REQUIRING  PARTS  notice  should  be 
printed  on  the  terminal  printer  in  materiel  control. 

2.  VIMS  should  look  up  in  the  vehicle  master  file  and  print  on 
the  NEW  DEFERRED  JOBS  REQUIRING  PARTS  notice  the 

Engine  description  (size,  no.  of  cylinders) 

Vehicle  type 
Model/Body  type 
T.O.  Reference 

Automatic  or  manual  transmission 

and  any  other  information  available  in  the  vehicle  master  record 
that  will  aid  materiel  control  in  ordering  the  parts. 


c .  Procedure 

1.  TAC:  It  is  unlikely  or  rare  that  DEFER/ADD  will  be  used  to 
defer  work  for  parts.  More  likely  used  to  defer  work 
for  lack  of  personnel.  In  order  to  defer  for  parts, 
we  generally  require  that  the  vehicle  come  into  the 
shop  and  we  will  open  a work  order  to  at  least 
determine  for  ourselves  what  parts  are  actually 
required.  Jobs  will  then  be  deferred  under  that  work 
order. 

SAC:  We  use  the  operator  care  centers  for  incoming  vehicle 
inspection.  We  can  determine  a vehicle's  need  for 
parts  at  the  operator  care  center  before  a work  order 
has  been  opened,  and  would  probably  use  the  DEFER/ADD 
quite  frequently  to  defer  jobs  for  parts  without 
opening  a work  order. 


d.  Implementation 

1.  The  model  software  will  not  allow  the  operator  to  return  to 

an  entry  on  the  displayed  form  once  he  has  indicated  it  to  be 
complete  with  a Line  Accept. 

NOTE:  This  was  an  implementation  oversight  in  several 

transactions  in  the  model.  The  operator  should,  in 
general,  have  complete  freedom  to  return  to  any  line  or 
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entry  and  be  allowed  to  alter  or  modify  it  before 
terminating  the  transaction. 


9.  DEFER/CHANGE 
a . Added  Feature 


1 .  An  option  should  be  provided  for  obtaining  a new  printed 
list  of  deferred  jobs  to  give  to  the  vehicle  operator,  to  insure 
that  his  list  is  accurate. 


10.  DEFER/DELETE 
a.  Added  Feature 

1.  If  DEFER/DELETE  is  used  to  delete  a job  that  was  deferred 
for  parts  (DFP),  a notice  should  be  printed  to  materiel  control  so 
that  they  can  take  appropriate  action  on  cancelling  ordered  parts 
and  updating  of  back-ordered  parts  file. 


11.  PARTS/REVIEW 
a.  File  Content 


1.  The  Back-Ordered  Parts  File  (BOPF)  entries  should  show 
which  parts  are  ordered  for  VDP  vehicles. 

2.  Each  entry  in  the  BOPF  display  should  leave  room  enough  to 
show  FSN,  Part  Nomenclature,  and  Document  No.  if  ordered  from 
supply. 

3.  Include  Order  Invoice  No.  in  BOPF  entry. 

4.  Show  priority  under  which  part  was  ordered  (is  FAD  code  any 
help?) . 

5.  Show  date  of  last  follow-up  action  on  overdue  parts 
(priority  and  date  of  last  follow-up  will  be  especially  important  in  the 
VDP  Summary).  For  supply  ordered  parts,  also  may  want  to  include  a 
2-character  alpha  code  (from  D18  report,  showing  delivery  status???) 
and  3-digit  Julian  EDD. 

6.  Show  cumulative  cost  for  entire  file,  broken  down  by  source 
(COPARS,  Supply). 
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7.  Costs  entered  in  BOPF  for  supply  ordered  parts  are  for 
estimate  only.  Actual  costs  will  be  charged  to  vehicles  when  VIM 
cards  from  the  1050  are  processed. 


b.  Forma t/Sequence 

1.  BOPF  should  be  sequenced  on  Vehicle  Reg.  No. 

2.  Each  page  of  the  BOPF  display  should  be  identified  as  Page 
m of  n,  in  order  to  know  how  long  the  file  is. 


c .  File  Size 


1.  The  BOPF  may  be  very  large  (several  hundred  entries).  The 
open  format  on  the  display  is  easy  to  read,  but  would  take  a long 
time  to  pass  the  whole  file  in  review.  Probably  would  use  a paper 
copy  of  the  file  for  reference  most  of  the  time. 


d .  Added  Features 


1.  PARTS/REVIEW  should  have  an  option  that  allows  addressing  a 
specific  vehicle  by  Vehicle  Reg.  No.,  to  avoid  having  to  page 
through  the  file  when  the  vehicle  no.  is  known. 

2.  PARTS/REVIEW  needs  a print  option. 

NOTE:  If  the  file  is  very  long,  it  is  probably  a good  idea 

to  print  a fresh  copy  of  the  file  during  a night  run,  to  be 
delivered  each  morning  to  materiel  control. 


12.  PARTS/ADD 
a.  General 

1 . Is  it  necessary  to  give  the  work  order  number  as  part  of 
the  entry?  There  is  none  if  the  job  was  deferred  using  DEFER/ADD. 


b.  Implementation 

1.  A DITTO  function  key  would  be  useful  in  PARTS/ ADD. 
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2.  On  second  and  subsequent  entries  the  software  could  repeat 
the  work  order  number  automatically  as  it  does  now  with  the  vehicle 
number. 

3.  Would  prefer  to  have  the  form  displayed  a line  at  a time  as 
needed,  rather  than  having  to  wait  for  a full  form  to  be  displayed. 

4.  Would  like  a system-supplied  date  as  an  option. 

5.  Need  more  space  for  part  nomenclature. 


13.  PARTS/CHANGE 

a.  Procedure 

1.  Transmit  the  PARTS  ARRIVAL  NOTIFICATION  directly  to  the 
workload  control  terminal  printer. 

b . Added  Features 


1.  The  PARTS/CHANGE  transaction  used  to  report  receipt  of 
parts  should  include  the  actual  date/time  of  receipt  of  parts. 

2.  The  PARTS  ARRIVAL  NOTIFICATION  should  show  the  actual  date 
and  time  of  receipt  of  parts.  Also,  the  headings  should  be 
corrected  to  show  DATE  RCVD  (it  now  says  DATE  ORDER). 

3.  In  addition  to  keying  into  the  file  by  vehicle  number, 
would  it  be  possible  to  key  on  vendor  invoice  number  or  supply 
requisition  number? 

4.  If  all  parts  arrive  for  a particular  job,  VIMS  should  check 
to  see  if  the  vehicle  may  already  be  in  the  shop.  If  so,  the  PARTS 
ARRIVAL  NOTIFICATION  should  say  so,  and  should  give  the  number  of 
the  open  work  order.  Workload  control  can  then  call  up  the  work 
order  and  add  the  deferred  job  while  the  vehicle  is  still  available. 

5.  When  materiel  control  enters  the  arrival  of  the  last  part 
for  a VDP  job  and  no  other  VDP  jobs  for  that  vehicle  are  still 
awaiting  parts,  the  vehicle  can  be  automatically  taken  off  VDP.  In 
this  case,  the  PARTS  ARRIVAL  NOTIFICATION  directed  to  workload 
control  should  show  the  VDP  removal  action  and  give  the  date  and 
time  that  it  was  taken.  The  VDP  removal  time  should  be  the  actual 
receipt  time  for  the  part,  which  may  differ  from  the  transaction 
time . 
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c.  Implementation 


1*  PARTS/CHANGE  transaction  needs  a DITTO  key, 

2.  The  BOPF  should  be  sequenced  by  vehicle  number, 

3.  The  model  doesn't  recognize  a bin  location  with  an  alpha 
character  as  the  first  character, 

4.  The  bin  location  field  should  be  4 places  to  allow  the  use 
of  the  'P'  suffix  showing  partial  availability  of  parts  for  a 
vehicle. 


NOTE:  This  comment  was  made  several  times.  In  fact,  the 

'P'  suffix  will  no  longer  be  needed,  because  entries  in  the 
deferred  maintenance  file  will  now  be  by  individual  job. 
Whenever  all  parts  for  a single  deferred  job  have  arrived, 
the  bin  location  will  be  filled  in,  to  indicate  that  the 
job  may  be  done,  A blank  bin  location  implies  that  all 
parts  necessary  to  accomplish  that  specific  job  have  not 
arrived. 


14.  PARTS/DELETE  • 
a . Implementation 

1.  Special  case  - if  for  a given  job  the  BOPF  shows  that  all 
parts  except  one  have  arrived  and  are  binned,  and  the  remaining  part 
is  DELETED,  VIMS  should  recognize  this  as  a completed  order  and 
should  generate  the  PARTS  ARRIVAL  NOTIFICATION. 


15.  PARTS/ISSUE 

a.  Format 

1.  The  wording  is  confusing  on  the  display  in  the  line  that 
identifies  the  work  order  against  which  parts  are  being  issued. 
Suggest  changing  it  to  read  "CHECK  THOSE  PARTS  TO  BE  ISSUED  AGAINST 
WORK  ORDER  nnnn". 

b . Implementation 

1.  Should  have  an  option  for  direct  entry  into  BOPF  for  this 
transaction  rather  than  requiring  the  operator  to  page  through  the 
file  to  find  parts  being  issued.  Suggest  a transaction  call  such  as 
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(ATTN) 

TRANSACTION  ? 

(PARTS/ISSUE) 

WHAT  WORK  ORDER  NO.  WERE  PARTS  ISSUED  TO? 

(4227) 

WHAT  VEHICLE  WERE  PARTS  ORDERED  FOR? 

If  no  vehicle  is  given,  the  operator  would  be  required  to  page 
through  the  file  as  he  does  now.  If  the  vehicle  .is  given,  VIMS 
would  locate  and  display  all  parts  ordered  against  that  particular 
vehicle. 

c . Added  Feature 


1.  On  PARTS/ISSUE,  check  if  part  was  issued  to  the  vehicle  for 
which  it  was  ordered.  If  not,  wipe  out  the  bin  location  from  the 
deferred  maintenance  file  entry  and  remind  materiel  control  to 
reorder  the  part  for  the  original  vehicle. 

d . Procedure 


1 . Need  to  be  able  to  recover  gracefully  when  a back-ordered 
part  is  drawn  out  by  a mechanic  who  then  discovers  that  the  wrong 
part  was  sent. 

2.  The  PARTS  ARRIVAL  NOTIFICATION  shows  details  of  all  parts 
and  bin  locations.  Workload  control  can  keep  this  on  file,  and  give 
it  to  the  mechanic  when  the  vehicle  returns  and  a new  work  order  is 
cut.  The  mechanic  in  turn  can  present  this  to  materiel  control  when 
collecting  the  parts  for  installation,  and  materiel  control  can  use 
this  as  the  source  document  for  the  PARTS/ISSUE  transaction. 

3.  Do  not  use  the  PARTS/ISSUE  to  make  actual  charges  against 
vehicles.  The  costs  in  BOPF  should  be  used  for  information  and 
estimating  purposes  only.  Use  BOPF  only  for  keeping  status  of  parts 
and  for  notifying  workload  control  of  parts  availability.  Cost  for 
parts  obtained  through  COPARS  will  be  charged  to  vehicles  when  the 
sales  slips  are  processed,  using  the  COPARS  transaction.  Costs  for 
parts  obtained  through  base  supply  will  be  charged  to  vehicles  as 
they  are  now,  when  the  VIM  cards  from  the  1050  are  processed  by 
VIMS. 
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16.  HCBS/REVIEW 


a.  File  Content 

1 . Include  a code  in  the  HCBS  master  file  to  show  whose  bench 
stock  each  item  belongs  to  (Tire  Shop,  Battery  Shop,  Allied  Trades, 
Refueling,  463L,  ...) 

2.  Expand  nomenclature  to  a more  intelligible  form. 

3.  Add  I&S  code  (Interchangeability  & Substitution).  E.g., 


b.  File  Sequence 

1.  Need  alternate  sort  sequences  for  the  HCBS  master  file. 

E.g.  , 

a.  Group  all  tires  by  tire  size 

b.  Sort  on  FSN 

c.  Sort  on  Item  Number 

c . General 

1.  The  file  as  displayed  by  HCBS/REVIEW  is  very  dense  and  hard 
to  read.  Question  its  usefulness.  Probably  would  use  the  printed 
copy  most  of  the  time,  since  the  file  tends  to  change  slowly. 

17.  HCBS/ADD 
a.  Implementation 

1.  If  an  item  is  deleted  from  the  HCBS  Master  file,  the  item 
number  could  be  reused  if  it  was  given  a progressive  alpha 
character,  e.g.  90,  90A,  90B,  90C,  etc. 


NOTE:  This  comment  was  made  because  the  model  does  not 

allow  one  to  reuse  an  item  number  after  an  item  is  deleted. 
New  items  are  automatically  given  the  next  higher  unused 
number.  This  was  done  to  avoid  the  possibility  of  having 
"Q-cards"  in  existence  with  the  same  item  number  but  for 
different  items.  The  volume  of  deletions  and  additions  to 


Ml 008  (Master) 

11008  (Interchangeable) 
11008  (Interchangeable) 


G78  x 15  tire 
750  x 15  tire 
855  x 15  tire 
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the  HCBS  master  file  appears  to  be  low  enough  so  that  it 
should  not  be  necessary  to  reuse  numbers. 

b . Added  Feature 


1.  When  adding  an  item  to  the  HCBS  file,  check  to  be  sure  an 
item  with  the  same  FSN  isn't  already  in  the  file. 


18.  HCBS/CHANGE 
a . Added  Feature 


1.  A HCBS/CHANGE  should  allow  for  generation  of  new  "Q-cards" 
since  data  has  changed. 


19.  HCBS/DELETE 
a . Implementation 

1 . We  need  to  have  a method  of  purging  the  file  of  deleted 
items  so  as  not  to  keep  assigning  numbers  infinitely. 

(See  note  under  HCBS/ADD,  Implementation) 

2.  May  want  double  verification  to  avoid  inadvertent 
deletions.  HCBS/DELETE  does  not  show  the  item,  it  simply  informs 
the  operator  that  the  designated  item  has  been  deleted.  May  want  to 
display  the  item  first  and  let  the  operator  see  what  it  is  before 
deleting  it. 


20.  HCBS/ ISSUE 

a.  Added  Features 

1 . Can  quantity  on  hand  be  tracked  and  made  available  to  the 
operator? 

b . Procedure 

1 . Probably  not  any  reason  to  continue  to  use  punched  cards  as 
Q-cards.  Could  just  be  printed. 
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c.  Implementation 


1 .  The  displayed  form  should  be  in  the  same  order  as  the 
source  document. 


21.  COPARS 

a.  Display  Format/Content 

1.  On  COPARS  sales  slip  entry  form,  remove  the  WNTY  MILES  item 
(warranty  is  always  for  a specified  length  of  time  only),  and  add  a 
DATE  OF  WNTY  item  since  the  date  of  warranty  may  be  different  from 
the  date  of  the  input  transaction. 

2.  The  COPARS  entry  form  should  include  an  item  for  Charge 
Code  (0,M,N) . 

3.  The  COPARS  invoice  number  should  be  part  of  the  input  data. 
Slips  are  filed  by  invoice  number  (both  vendor  and  materiel 
control).  This  will  enable  us  to  locate  invoice  and  prove  warranty 
on  parts.  The  invoice  number  (5-digits)  should  also  appear  in  the 
Parts  Warranty  file. 

4.  The  displayed  form  should  match  the  order  of  items  on  the 
sales  slip. 

5.  The  COPARS  sales  slip  display  should  show  the  vehicle  reg. 
no. , the  make/type  and  the  engine  displacement. 

6.  The  job  number  should  be  included  as  a data  item  for  each 
part. 

7.  The  WNTY  indicator  data  item  on  the  COPARS  input  form  is 
redundant.  An  entry  in  WNTY  DAYS  implies  special  warranty. 

8.  Would  like  the  form  on  the  display  for  COPARS  input  to  be  a 
facsimile  of  the  COPARS  sales  slip.  It  would  be  easier  to  fill  in. 

9.  Although  parts  warranty  data  may  be  printed  on  work  orders, 
show  the  parts  warranty  data  on  the  display  at  finish  of  COPARS 
transaction  (use  split  screen  showing  both  COPARS  sales  slip  data 
and  parts  warranty  data) . Use  this  for  updating  the  Parts  Warranty 
file  in  the  case  where  an  item  in  PWF  is  replaced  by  a later 
warranty. 


102 


NOTE:  If  warranty  data  is  entered  for  any  item  on  the  sales 

slip,  at  the  end  of  the  COPARS  transaction  VIMS  should  scan  the 
Parts  Warranty  file  and  display  all  current  part  warranties  for 
the  vehicle,  using  a split  screen.  If  the  operator  finds  that  an 
item  on  the  sales  slip  is  a replacement  for  a part  under 
warranty,  he  should  X the  warranty  on  the  display,  causing  VIMS 
to  remove  it  from  PWF.  The  new  warranty  information  will  be 
added  to  PWF  as  a normal  part  of  COPARS  processing. 

NOTE:  If  the  above  case  is  simply  an  exchange  of  a part  under 

warranty,  the  cost  should  be  left  blank  when  entering  the  item 
on  the  displayed  sales  slip  form.  The  warranty  information  will 
be  used  to  update  the  Parts  warranty  file  in  the  usual  fashion, 
but  no  cost  will  be  charged  to  the  vehicle  and  the  item  will  not 
be  part  of  the  A&F  output  record. 

b .  Funds 


1,  Need  to  address  how  to  handle  additional  charges,  freight 
charges,  telephone  charges,  Non-Price  Listed  (NPL)  items  surcharge, 
adjusted  prices  and  credits. 

2.  Materiel  control  would  like  to  have  the  system  maintain  a 
running  balance  of  remaining  monthly  COPARS  funds.  This  might  be 
queried  and/or  shown  on  COPARS  sales  slip  input  display,  and  updated 
after  each  sales  slip  is  input.  Should  program  in  the  algorithm  to 
properly  account  for  NPL  service  charge  which  is  a function  of  the 
NPL  total  cost. 

c .  General 


1.  Accumulation  of  COPARS  data  is  easily  accomplished  and  will 
serve  many  purposes:  Procurement  requirement,  A&F  funds,  back- 
ordered parts  status,  VDP  status,  audit  trail,  contractor 
performance,  etc. 

d .  Procedure 


1.  Need  to  get  warranty  update  into  PWF  for  items  that  were 
simply  exchanged  under  warranty.  Have  COPARS  make  out  a sales  slip 
showing  exchange  only,  and  use  this  as  source  document  for  update  of 
PWF  (see  note  under  item  9 of  Display  Format/Content  paragraph 
above) . 


2.  The  date  on  COPARS  slips  should  be  Julian  date. 
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3.  If  replacing  a part  under  warranty,  print  a management 
notice  in  workload  control.  (??) 

4.  There  may  be  an  item  on  a COPARS  sales  slip  to  cover 
freight  charges. 

5.  On  the  transaction  prompt,  allow  entry  of  work  order  number 
or  vehicle  number.  Use  work  order  number  for  direct  issue  and 
vehicle  number  for  back-ordered  parts.  Also  allow  for  a blanket 
work  order  number  such  as  H8888,  to  accomodate  sales  slips  made  out 
for  parts  acquired  for  high  cost  bench  stock  rather  than  for  a 
specific  vehicle. 

e.  Implementation 

1.  All  numeric  fields  should  be  right- justified  by  the 
computer  after  they  have  been  entered. 

2.  Software  should  check  date,  and  question  any  slip  that  is 
more  than  five  days  old. 

3.  Allow  for  entry  of  a discount  percentage  with  fractional 
value  (e.g.  33  1 / 3% ) * 

4.  If  a given  discount  percentage  value  is  the  majority  case, 
it  could  be  made  a default  case  for  input. 

5.  Since  COPARS  slips  will  likely  be  entered  in  a batch,  at 
the  end  of  the  transaction  software  should  cycle  back  for  another 
slip  and  not  return  to  the  top  level.  On  recycle,  software  should 
erase  the  data  from  the  display  but  could  leave  headings  and  date 
(allow  for  override  of  date  if  desired). 

6.  Do  not  display  entire  blank  form  at  the  beginning  of  the 
transaction.  Build  the  form  a line  at  a time,  as  needed. 

7.  The  model  would  not  allow  operator  to  return  to  a 
previously  entered  line  to  make  corrections. 

NOTE:  Implementation  oversight. 
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22.  FUEL 


a.  Error  Checking 

1 . Enter  the  fuel  tank  capacity  for  each  vehicle  as  part  of 
the  vehicle  master  record.  When  inputting  fuel  consumption  data, 
question  any  fuel  quantity  that  exceeds  the  vehicle's  tank  capacity. 

2.  Question  any  oil  quantity  over  2 quarts. 

b.  Implementation 

1.  Delete  or  redefine  the  action  of  the  QUIT  function  key 
during  this  transaction.  Otherwise,  may  wipe  out  many  entries. 

2.  Like  the  result  of  the  DITTO  key,  but  it  should  be  easier 
to  use. 

NOTE:  Everyone  liked  having  a DITTO  key  that  would 

automatically  repeat  the  field  above.  The  choice  of  key  for  the 
function  was  unfortunate.  The  quote  mark  was  selected,  which 
requires  operation  of  the  SHIFT  key. 

3.  Numeric  fields  should  be  right-justif ied  as  soon  as  a Line 
Accept  is  given. 

4.  Enter  the  date  only  once  and  assume  it  repeats  for  each 
entry  unless  it  is  specifically  changed. 

5.  The  Issuing  Org.  and  Date  fields  could  be  "auto-duped". 

6.  The  model  would  not  allow  the  operator  to  return  to  a 
previously  accepted  line  to  make  corrections. 

7.  In  the  error  message  that  questions  fuel  and  oil  quantity 
entered,  change  "INVALID"  to  "QUESTIONABLE". 

c . Input  Data 


1.  A separate  transaction  (FUEL/OB)  ? is  suggested  to  handle 
the  reporting  of  off-base  fuel  issue.  In  this  case  it  is  necessary 
to  enter  total  cost  of  gas  and  oil,  whereas  cost  is  not  required 
when  reporting  on-base  issue. 

2.  Need  space  to  enter  the  Using  Org. 
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d . Display  Format 


1.  Revise  the  FUEL  input  displayed  form.  Include  the 
following  items  from  left  to  right: 


Vehicle 
Assigned  Org 
Fuel(gals) 
Oil(qts) 

Date 

Issuing  Org 


- 8 characters 

- 2 characters 

- 2 digits  (whole  gallons) 

- 1 digit 

- 5 digit  Julian  (blank  means  repeat) 

- 2 characters  (blank  means  repeat) 


2.  Make  the  fuel  quantity  field  2 digits.  Only  enter  whole 
gallon  amounts  (the  automatic  fuel  pump  data  is  only  whole  gallons 
now) . 

3.  Data  entry  would  go  much  faster  if  the  operator  didn  t have 
to  keep  repeating  the  date.  Suggest  it  be  entered  only  once  and 
carry  forward  until  changed. 

e.  Added  Features 

1 . Would  like  a log  of  all  FUEL  entries  that  resulted  in  error 
messages,  including  an  indication  whether  each  such  entry  was 
cancelled  or  whether  the  operator  forced  its  acceptance. 

2.  Would  like  a log  (in  Using  Org.  sequence)  of  batch  input. 
Compute  and  show  total  gallons  of  fuel  and  total  quarts  of  oil  by 
Using  Org. 

3.  Should  be  able  to  roll  back  to  previous  pages  of  FUEL 
entries  for  review. 

4.  Need  some  signal  to  notify  the  operator  that  an  entry  has 
failed  one  of  the  error  checks.  If  he  is  not  watching  the  screen  he 
may  miss  the  error,  and  may  enter  the  next  line  on  top  of  the 
previous  one.  Suggest  an  audible  signal  that  coincides  with  the 
error  message  and  persists  until  the  operator  clears  it  with  a CLEAR 
key. 
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23.  TIME/INPUT 


a . Employee  I.D. 

1.  Most  felt  that  TIME/INPUT  was  slow  in  moving  from  man  to 
man.  Instead  of  being  prompted  by  employee  name  in  alphabetical 
sequence,  it  was  suggested  that  the  operator  identify  each  employee 
using  a 3-digit  employee  number  (most  suggested  using  the  last  3 or 
4 digits  of  the  SSAN).  This  would  be  faster  and  would  not  require 
the  time  cards  to  be  pre-sorted  before  entering  a batch. 

2.  If  3 or  4 digit  employee  I.D.  number  is  used  there  will  no 
longer  be  any  need  for  a distinction  between  batch  input  and  single 
employee  input. 

b . Implementation 

1 . The  date  should  be  entered  only  once  as  part  of  the 
transaction  call,  and  should  be  carried  forward  throughout  the 
transaction  from  employee  to  employee. 

2.  The  legality  of  the  shift  code  should  be  checked. 

3.  The  DITTO  function  should  work  the  same  as  it  does  in  the 
FUEL  transaction.  It  should  repeat  the  actual  data,  not  simply 
leave  DITTO  marks. 

4.  Addition  in  TIME/INPUT  is  only  accurate  to  .1  hrs. 

NOTE:  Becuase  of  problems  with  the  arithmetic  package  used 

in  model  software,  the  validity  checking  routine  would 
accept  7.9  or  8.1  hours  as  8.0  hours  of  first  shift  time. 

5.  Allow  time  to  be  entered  as  2 digits,  with  decimal  point 
understood  between  them. 

6.  As  soon  as  shift  code  is  entered,  do  an  automatic  carriage 
return  and  line  feed  to  position  the  cursor  at  the  start  of  the  next 
line  (see  Format,  item  1,  below  for  suggested  redesign).  Prefer  to 
always  enter  shift  code  and  have  automatic  step  to  next  line,  rather 
than  leaving  it  blank  to  indicate  no  change  and  having  to  use 
Carriage  Return  to  step  to  next  line.  By  always  entering  it  rather 
than  only  when  it  changes,  the  operator  actions  are  more  consistent 
and  mechanical  and  require  less  thought. 
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c.  Format 


1.  The  displayed  form  in  TIME/INPUT  needs  to  be  redesigned  to 
follow  the  same  sequence  of  data  items  as  the  time  cards.  Should  be 
able  to  specify  the  date  at  the  beginning  of  the  transaction  and 
have  it  carry  forward  from  employee  to  employee  unless  specifically 
changed.  Reorder  the  displayed  form  to  show  from  left  to  right: 


Work  Order  No. 
Job  No. 

Time 

Shift  Code 


(4  digits) 
(2  digits) 
(2  digits) 
(1  digit) 


NOTE:  Subjects  experimented  with  this  revised  format 

during  the  testing  period,  and  found  it  to  be  much  easier 
to  use  than  the  format  that  was  implemented  in  the  model. 


d.  Keyboard 

1 . TIME/INPUT  would  be  much  easier  if  the  TAB,  DITTO  and  DONE 
function  keys  were  located  with  the  numeric  keypad  cluster.  It 
would  allow  holding  the  source  document  in  one  hand  while  entering 
the  data  with  the  other. 

NOTE:  The  CRT  used  for  testing  has  a numeric  key  cluster 

on  the  right  of  the  keyboard  which  may  be  used  in  lieu  of 
the  numerics  that  are  part  of  the  standard  typewriter 
layout. 

e.  Added  Feature 


1 . R&A  would  like  to  have  some  sort  of  end-of-day  closeout 
that  would  show  any  employees  who  have  not  yet  submitted  a time  card 
for  the  day. 

2.  Should  be  able  to  recall  for  examination  and/or  correction 
an  employee  time  card  input,  even  if  it  has  been  accepted  and 
processed. 

3.  In  resolving  time  card  errors,  need  to  be  able  to  get  back 
into  CLOSED  work  orders  to  make  corrections  (e.g.  job  on  work  order 
that  in  fact  was  not  done  and  hence  has  no  time  charged  to  it). 
Necessary  only  for  work  orders  closed  less  than  6 days. 

4.  Should  be  able  to  print  more  than  one  copy  of  the  Error 
Suspense  File.  R&A  needs  a copy,  and  will  probably  want  another  to 
send  to  shop  supervisors.  May  want  to  shred  out  a second  copy  by 
work  center. 
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5.  Can  software  check  for  work  orders  with  jobs  left  hanging 
with  no  time  charged  aginst  them?  In  current  VIMS  this  is  a 
frequent  cause  of  work  orders  failing  to  close  properly.  Suggest  a 
list  of  all  work  orders  closed  over  2 days  without  time  charged 
against  all  jobs. 

24.  TIME/EDIT 

a.  Added  Feature 

1.  R&A  would  like  an  ESF/REVIEW  transaction,  to  review  the 
time  card  input  Error  Suspense  File. 

25.  VDP/ SUMMARY 

a.  Display  Content 

NOTE:  Although  the  VDP/SUMMARY  transaction  was  not  tested,  it 

was  discussed  by  some  of  the  subjects,  and  the  following 
comments  record  their  suggestions  regarding  content  of  the 
VDP/SUMMARY  display  beyond  that  which  was  specified  on  paper. 

1.  For  each  part,  show  DATE  DUE/RECEIVED  and  BIN  LOCATION  if 
received. 


2.  Add  FSN  and  Document  No.  for  supply-ordered  parts. 

3.  For  each  vehicle,  show  the  number  of  days  and  hours  on  VDP. 
Useful  for  standup  briefings. 

4.  NORS  vehicles  on  VDP  - NORS  vehicles  can  be  identified  as 
such  in  the  vehicle  master  file.  The  VDP  Summary  should  have  a 
separate  breakout  of  NORS-reportable  vehicles. 

26.  WARRANTY/UPDATE 

NOTE:  This  transaction  was  not  implemented  in  the  model, 

a.  General 

1.  Need  a PARTS  WARRANTY  REVIEW  capability,  and  a general 
update  capability. 

2.  Need  to  provide  for  updating  the  parts  warranty  file  with 
special  warranty  data  for  supply-ordered  parts. 
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3.  Need  a parts  warranty  update  capability  separate  from  the 
sales  slip  transaction. 

27.  SPECIAL  INQUIRIES 

a.  Special  Inquiries  and  Reports 

1.  Workload  control  would  like  a query  capability  that  would 
allow  them  to  review  the  internal  271  for  any  vehicle,  to  review 
such  items  as  TCTO  history  or  special  inspection  data. 

2.  R&A  would  like  to  be  able  to  obtain  a weekly  QC  INSPECTION 
SUMMARY.  Sample  Format: 

Date  WO  # Job  # Action  Code  Svs  Code  Work  Ctr  Mech 
• » • » » • » 

> • » • • » » 

» » » » • • • 

Total  W/0  Closed  

Total  W/0  Insp.  

Total  Rejected  

% Inspected  

% Rejected  

3.  Workload  control  - Will  the  system  compute  a VDM  summary 
daily  so  I don't  have  to  do  it  manually?  I spend  a lot  of  time 
preparing  this  at  commander's  request. 

M.  Should  be  a capability  to  query  the  data  base  to  tie 
VEHICLE  to  WORK  ORDER  NUMBER  to  JOBS  to  COPARS  INVOICE.  This  trail 
could  be  used  for  audit  trails  to  verify  parts  installation 
requirement  by  I.G.,  auditor,  Vehicle  Maintenance  Superintendent, 
etc.  (Reviewing  personnel  said  this  happens  frequently). 

5.  Maintenance  control  would  like  an  inquiry  capability 
against  old  work  orders  that  would  allow  one  to  identify  all  parts 
(and  their  source)  that  were  obtained  under  that  work  order. 

6.  Workload  control  would  like  to  be  able  to  retrieve  past 
work  orders  for  a vehicle.  This  data  is  usually  needed  while  the 
vehicle  is  in  shop,  generally  within  1/2  hour  or  less  from  the  time 
requested.  Currently  this  is  done  by  requesting  R&A  to  pull  old 
copies  from  their  files. 

7.  Need  a capability  for  materiel  control  to  screen  the  BOPF 
for  availability  of  specific  part  to  avoid  VDP  on  another  vehicle 
(cannibalization  from  the  BOP  bins).  Currently  done  by  searching 
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for  parts  ordered  under  the  same  Management  Code  and  for  the  same 
vehicle  year. 

8.  To  investigate  repeat  maintenance,  need  a search  and 
retrieve  capability  against  Historical  Repair  file.  E.g.,  all 
replacements  of  muffler  (system  code  084)  on  Chevy  pick-ups  for  past 
six  months  (specify  Management  Code  to  indicate  type  of  vehicle). 

28.  KEYBOARD 

a.  Numeric  Layout 

1.  Subjects  were  divided  on  preference  for  numeric  keypad  over 
the  typewriter  layout  of  numerics.  Generally,  those  with  more 
typing  experience  gravitated  toward  the  typewriter  layout.  R&A  and 
materiel  control  tended  to  use  the  numeric  keypad  more  often. 

2.  Two  people  from  R&A  thought  it  might  be  convenient  to  have 
an  alternate  layout  of  numerics  in  the  same  position  as  numerics  on 
the  keypunch. 

3.  One  subject  liked  the  numeric  keypad  but  complained  about 
the  inconvenience  of  having  to  return  to  the  alpha  keyboard  to  enter 
the  embedded  alpha  character  in  the  vehicle  registration  number. 

b . Key  Glare 


1 . One  subject  complained  about  annoying  glare  from  overhead 
lights  reflecting  from  the  keycaps. 

c .  Function  Keys 


1.  Two  subjects  suggested  that  the  QUIT  function  key  be 
isolated  from  other  function  keys  to  reduce  the  possibility  of 
hitting  it  accidentally. 

29.  GENERAL 

NOTE:  The  remaining  comments  include  those  which  seemed 

worthwile  recording  but  did  not  fit  easily  into  any  of  the 
previous  categories. 

1.  If  the  wrong  COPARS  part  is  received,  need  procedures  that 
will  allow  one  to 

a.  cancel  the  charge  to  the  vehicle 
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b.  place  the  job  back  on  deferred  status  (showing  part 
not  arrived) 

c.  notify  materiel  control  to  get  COPARS  credit 

2.  At  Hanscom,  the  incoming  vehicle  inspector  fills  in  the 
work  order  and  brings  it  to  workload  control  for  completion. 

3.  Workload  control  needs  to  have  better  feedback  from 
mechanics  to  show  exactly  what  maintenance  was  performed.  It  would 
help  often  times  to  explain  what  otherwise  seems  to  be  excessive 
labor,  and  would  help  in  maintaining  better  historical  repair 
records. 


4.  If  a vehicle  is  OTR-suspended,  do  not  allow  another  work 
order  to  be  opened.  Could  be  allowable  if  ACC-suspended,  but  should 
at  least  question. 

5.  "Workload  control  will  need  a quiet  environment  to  be  able 
to  concentrate  on  what  he  is  doing  at  the  terminal". 

6.  Should  be  able  to  recall  for  viewing  any  work  order 
regardless  of  status,  as  long  as  it  is  still  in  an  on-line  file. 
Includes  work  orders  that  are 

OPEN 

SUSPENDED  (OTR,  VDP,  ACC) 

CLOSED  (less  than  6 days) 

7.  All  numeric  fields  should  be  right- justified  on  printouts. 

8.  Prefer  to  have  all  forms  displayed  one  line  at  a time,  with 
new  lines  given  as  needed.  Much  faster  than  waiting  for  a full  form 
to  be  displayed. 

9.  A single  character  call  to  transactions  would  be  easier  and 
faster  once  familiar  with  transactions. 

10.  Workload  control  is  concerned  with  doing  away  with  the  271 
Vehicle  Historical  Record.  It  contains  much  information  that  would 
still  be  required. 

Vehicle  Warranty 

Parts  Warranty  and  Parts  T.O.  Reference 
Repair  History 
TCTO  Actions 
Undercoatings 
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Wheelbearing  Repack 
Special  Inspections 


11.  The  Standard  Hours  Estimates  on  work  orders  are  very 
questionable.  They  very  often  are  grossly  off  from  the  time 
actually  spent  on  a job,  for  legitimate  reasons.  Generally  not  a 
good  idea  to  use  these  as  a basis  for  policing  the  mechanics. 

Should  be  used  for  load  planning  and  estimating  purposes,  not  as  a 
club  to  hold  over  the  shop  personnel. 

12.  In  the  case  of  disposition  of  a vehicle,  need  a cleanup 
procedure  to  purge  the  system  of  back-ordered  parts,  pending  jobs, 
scheduled  maintenance,  parts  warranty,  etc. 

13.  R&A  will  need  a capability  to  update  the  Employee  Master 
File  (e.g.  new  employee,  deletion  of  employee,  change  of  work  center 
assignment,  etc.). 

14.  There  should  be  a capability  to  void  or  cancel  a work  order 
once  opened.  This  could  arise,  for  example,  due  to  mission 

req uests. 


15.  Should  be  able  to  print  any  currently  displayed  image;  for 
example,  the  scheduled  or  deferred  maintenance  displays  for  a given 
vehicle  as  they  appear  during  OPEN. 

16.  Itemizing  to  the  individual  job  level  may  result  in  a very 
large  deferred  maintenance  file. 

17.  May  be  able  to  do  away  with  the  vehicle  SERV-O-PLATE. 

18.  An  outlying  work  center  could  have  a printer  only;  they 
could  call  in  for  a work  order  and  have  it  printed  out  locally. 

19.  Do  not  allow  extra  job  space  on  a work  order  that  requires 
special  approval.  (In  manual  system,  extra  job  space  is  stamped  out 
to  insure  no.  unauthorized  jobs  are  added  on  after  approval). 

20.  Pease  has  a fleet  of  487  vehicles.  An  average  of  300 
deferred  work  orders  on  approximately  200  vehicles,  with  an  average 
of  2 line  items  per  work  order.  Pease  has  an  estimated  400  - 500 
back-ordered  parts  at  any  given  time. 

21.  Dover  has  a total  fleet  of  about  650  vehicles,  of  which  465 
are  registered. 
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22.  SAC  uses  operator  care  centers  for  incoming  vehicle 
inspection. 
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SECTION  VI 


SUMMARY 


SPECIFIC  DESIGN  GUIDANCE 

The  primary  result  of  testing  was  the  accumulation  of  a large 
volume  (see  Section  V)  of  specific  guidance  that  will  serve  as  input 
to  the  development  of  specifications  for  a full  prototype  of  on-line 
VIMS.  As  pointed  out  earlier,  the  feedback  from  testing  reveals 
that  there  are  some  major  changes  to  be  considered.  Careful  study 
and  review  of  comments  from  testing  is  recommended.  Major 
modifications  should  be  validated  if  possible  by  discussion  with 
functional  personnel. 


GENERAL  DESIGN  GUIDANCE 

In  addition  to  the  specific  guidance  referenced  above,  the 
testing  pointed  up  a number  of  more  general  design  guidelines  that 
merit  a separate  mention. 

a.  Display  formats  should  be  designed  to  match  source 
documents.  This  is  especially  important  when  displaying  a form  for 
data  entry.  The  data  entry  task  is  much  easier  if  the  items  on  the 
input  form  are  in  the  same  sequence  as  they  are  on  the  source 
document. 


b.  When  displaying  a form  that  allows  for  multiple  entries,  it 
is  more  efficient  to  build  the  displayed  form  one  line  at  a time  as 
needed,  rather  than  initially  displaying  a multi-line  blank  form. 

c.  From  the  operator's  veiwpoint,  it  is  expedient  to  be  able 
to  enter  numeric  data  without  concern  for  field  justification  (e.g., 
allow  entry  of  08,  8,  8.,  8.0).  However,  once  the  data  has  been 
accepted,  software  should  right  justify  all  numeric  fields  for 
better  legibility. 

d.  As  nearly  as  possible,  the  operator  should  have  as  much 
freedom  when  filling  in  forms  on  the  display  as  he  would  have  when 
filling  in  a form  with  a pencil.  That  is,  he  should  be  allowed  to 
space  around  at  will,  to  erase  and  correct,  to  skip  entries  or 
return  to  previous  ones,  to  enter  items  out  of  sequence,  or  even 
"tear  up"  the  form  and  start  again. 
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e.  Don't  build  in  overly  restrictive  self-protection*  Trust 
the  operator  to  know  his  job.  For  example,  don't  disallow  override 
of  system-supplied  time/date  because  it  might  be  used  to  fudge  VOC 
time.  Allow  the  override,  and  if  necessary  keep  a management  log  of 
all  exceptions.  Unnecessary  restrictions  are  a frustration  to 
operators  who  must  find  ways  of  "getting  around”  the  system  in  order 
to  accommodate  real  life  exceptions. 

f.  Even  though  a transaction  has  been  completed,  there  should 
be  a provision  for  the  operator  to  undo  or  nullify  it,  for  whatever 
reasons  he  may  deem  it  necessary. 

g.  The  use  of  labelled  function  keys  is  recommended.  Care 
must  be  taken  to  insure  that  the  meaning  of  individual  function  keys 
remains  consistent  from  one  transaction  to  another. 

h.  When  designing  formats  for  presentation  of  data  on  the 
display,  keep  them  open  and  uncrowded  for  better  legibility.  Lists 
and  tables  are  much  easier  to  read  if  they  are  double  spaced. 

i.  Titles  should  be  used  liberally  on  displays  and  printouts, 
so  that  they  are  easily  identified  and  as  self-explanatory  as 
possible. 

j.  A general  print  capability  should  be  provided,  that  would 
allow  an  operator  to  obtain  a printed  copy  of  any  static  image  on 
the  CRT. 


k.  Data  entry  should  be  reduced  to  a minimum,  by 

• Using  internally  retrieved  data  wherever  possible. 

• Implementing  a DUP  or  DITTO  function. 

• Implementing  an  implied  DUP  wherever  possible. 


POTENTIAL  USER  ACCEPTANCE 

As  may  be  seen  from  the  subject  evaluations  in  Appendix  I,  user 
acceptance  was  surprisingly  good.  We  were  prepared  for  more 
resistance  to  change  than  we  encountered • In  retrospect,  we  feel 
that  this  acceptance  may  be  attributable  to  the  following  reasons. 

a.  The  proposed  on-line  capability  does  not  represent  a major 
departure  from  current  procedure.  The  operator  s use  of  the 
terminal  is  primarily  to  assist  him  in  completing  tasks  which  he  is 
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already  performing  in  the  manual  system.  As  a result  there  is  a 
strong  parallel  between  present  and  proposed  methods. 

b.  In  addition  to  keeping  the  vehicle  maintenance  management 
data  more  current  and  accurate,  the  transactions  generally  offer 
some  direct  and  immediate  benefits  to  the  operator,  such  as 
performance  of  file  look-ups,  automatic  calculations,  immediate 
error  checking,  automatic  posting,  etc. 

c.  The  operator's  view  of  the  on-line  system  that  was 
promoted,  that  of  a "fast  file  clerk"  to  assist  in  performing 
designated  tasks,  leaves  the  operator  with  the  feeling  that  he  is  in 
control  rather  than  being  driven  by  the  computer.  This  was  enhanced 
by  the  fact  that  the  operator  could  always  resort  to  the  QUIT 
function  key  at  any  time  to  nullify  any  transaction  no  matter  how 
far  he  had  progressed  with  it  (short  of  actual  completion). 

Comments  made  by  subjects  during  testing  and  in  their  evaluation 
folders  indicate  that  they  were  pleased  with  the  responsiveness  of 
the  model.  It  should  be  noted  that  the  model  represented  probably 
the  optimum  in  responsiveness,  since  1)  it  was  run  on  a dedicated 
computer,  2)  the  data  files  were  small,  3)  the  line  speed  between 
terminal  and  computer  was  2400  bps,  and  4)  the  high  speed  printer 
was  used  during  testing. 

To  the  extent  that  any  of  these  factors  may  degrade  in  actual 
implementation,  the  responsivness  will  degrade  accordingly.  This 
will  certainly  have  an  effect  on  user  acceptance,  and  there  is  a 
point  where  response  can  become  so  poor  as  to  make  the  system 
totally  unacceptable  to  a user  regardless  of  the  other  benefits  it 
may  offer. 

While  this  testing  made  no  attempt  to  measure  user  tolerance  to 
degraded  response,  this  is  certainly  an  important  factor  to  be 
considered  in  subsequent  design  and  implementation  planning. 


THE  MODELING  APPROACH 

Finally,  we  feel  that  the  development  of  the  model  and  the 
subsequent  testing  of  the  model  by  functional  personnel  has  shown 
this  to  be  an  effective  approach  to  system  design*  Construction  of 
a model  forces  system  designers  to  a level  of  detail  that  is  harder 
to  accomplish  on  paper  alone.  It  also  forces  early  consideration  of 
the  relationships  and  interdependencies  of  the  pieces  of  a system. 
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The  model  proved  to  be  an  excellent  vehicle  for  involving 
potential  users  in  design  discussions.  Although  imperfect,  the 
model  is  tangible  and  is  far  more  thought  stimulating  than  a design 
document.  By  getting  potential  users  really  involved  in  the  early 
stages  of  system  design,  there  is  a much  better  opportunity  to  shape 
a final  system  that  will  be  responsive  to  user  needs.  The  resulting 
final  system  will  require  fewer  modifications  and  retrofits,  and 
should  meet  with  wider  user  acceptance  by  acknowledging  more  closely 
in  the  design  the  real  world  in  which  it  will  operate. 


118 


V 


APPENDIX  I 


SAMPLE  COMMENTS  FROM  EVALUATION  FORMS 

1 .  What  is  your  opinion  of  paperwork  and  data  management  in  Vehicle 
Maintenance? 

"The  Vehicle  reporting  system  in  use  today  (VIMS)  is  a workable 
system,  but  too  much  time  must  be  spent  making  it  so  on  a day  to  day 

basis In  R&A,  too  much  time  is  spent  as  a bookkeeper,  and 

making  the  system  work.  VIMS  is  too  open  to  errors.  The  lag  time 
from  source  to  end  product  is  too  long." 

"Too  slow  in  processing  the  paperwork  due  to  the  number  of  people 
that  is  involved." 

"Workload  control  has  seven  different  listings  to  check  just  to  open 
a work  order. . . . 


2.  What  was  your  initial  impression  of  the  model? 

"I  was  very  impressed.  It's  the  type  of  system  we  have  needed  for  a 
long  time." 

"I  was  under  the  impression  that  it  was  going  to  be  very  complicated 
and  confusing,  not  ever  having  any  affiliations  with  computers 
before  this  day." 

"I  was  impressed  by  the  overall  speed.  The  way  of  eliminating 
errors  was  really  outstanding." 


3.  Were  you  uneasy  or  relaxed  at  first  and  did  this  feeling  change? 

"I  was  uneasy  to  some  extent,  but  soon  realized  that  I had 
visualized  a system  more  complex  than  actually  was  being  introduced. 
Uneasiness  decreased  considerably  when  the  model  of  the  system  was 
shown,  and  by  noon  of  the  first  day  I felt  completely  at  ease..." 

"I  was  a little  uneasy,  as  I am  not  a typist,  and  the  keyboard  made 
me  a little  nervous.  But  within  the  first  hour  of  operating  the 
keyboard  I was  really  surprised  at  the  ease  of  and  the  speed  I could 
write  a work  order." 
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4.  What  was  the  hardest  area  for  you  to  get  used  to? 

"Knowing  what  keys  on  the  keyboard  to  use  and  learning  the  location 
of  them." 

"Not  having  the  paper  work  in  my  hand  and  knowing  that  I have  the 
control." 

"As  an  R&A  type,  not  having  immediate  access  to  what  was  going  on  in 
the  shop  maintenance  and  materiel  control  such  as  I am  accustomed  to 
having,  although  it's  always  after  the  fact." 


5.  What  were  your  main  likes  and  dislikes? 

"My  main  like  is  that  it  will  move  most  of  the  input  to  its  source, 
and  give  maintenance  fast  response  to  their  input,  and  give  R&A  more 
time  to  do  their  real  job." 

"The  speed  and  legibility  of  all  transactions  and  not  having  to 
check  listings  or  cards  for  all  static  data." 

"The  speed  of  transactions.  The  information  appears  before  you  on 
the  CRT  which  will  cut  down  on  hours  a day  by  not  having  to  check 
all  the  listings." 

"My  dislikes. . .pertain  to...  the  lack  of  seeing  how  our  present  A, 

B,  C,  and  272  cards,  or  formats  will  look  in  the  new  system,  as 
there  is  not  enough  vehicle  static  information  in  the  present 
system.  And  I believe  the  headings  need  realignment." 


6.  What  do  you  see  as  the  main  to  least  benefits? 

"Never  lets  you  forget  or  overlook  scheduled  maint. -deferred  parts, 
e tc . " 

"Immediate  recall  of  all  deferred,  repeat  and  scheduled  maintenance 
when  opening  a work  order  that  might  be  overlooked  under  the  present 
system. " 

"Managers  will  have  current  information  available  as  needed. 

Maintenance  Control  will  have  the  most  current  information  available  • 

to  them  at  all  times." 

"Workload  Control  will  have  more  information  quicker  with  less 
chance  for  error.  ...  Materiel  Control  will  have  more  current 
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information  to  work  with.  A knowledge  of  all  Deferred 
transactions. " 


7.  What  areas  were  in  most  need  of  improvement? 

"Accident  work  orders." 

"Manhour  reporting." 

"The  work  order  should  contain  as  much  information  as  possible  as  to 
the  description  of  the  vehicle  components  such  as  body  type,  wheel 
base,  engine  size  and  no.  of  cylinders.  Also,  the  parts  manual 
number  should  be  noted  on  the  initial  work  order  for  the  mechanic's 
reference  when  ordering  parts." 

"Further  research  should  be  done  in  the  manhour  accounting  system  to 
insure  that  the  mechanic  did  actually  work  on  the  vehicle  ....  A big 
headache  in  manhour  accounting  now." 

"Some  of  the  information  should  be  rearranged  to  a different  place. 
Warranty  Parts,  for  example..." 

"At  this  stage  I think  more  retrieval  capability  is  needed." 

8.  How  do  you  think  others  will  accept  this  concept  of  data 
handling  in  maintenance? 

"I  think  as  a whole  this  system  will  be  accepted  by  all  maintenance 
personnel,  but  of  course  you  will  always  find  your  hard  heads  that 
don't  like  to  change..." 

"It  will  take  some  convincing  to  get  people  to  rely  on  the  system  as 
it  did  under  the  3500  system.  Most  will  not  want  to  do  away  with 
the  status  boards,  but  if  a listing  or  listings  are  run  once  a week 
if  necessary,  as  a backup,  I believe  they  will  see  the  advantages  of 
the  system  quicker." 

"I  think  acceptance  of  this  concept  will  be  easy." 

"The  overall  majority  will  at  first  not  trust  the  system.  I feel 
after  seeing  it  operate  most  maintenance  managers  will  like  the 
system. " 


121 


"I  think  initially  that  acceptance  will  be  cautious  and  perhaps 
slow,  but  I think  training  and  exposure  will  eliminate  this  initial 
apprehension. " 


9.  Do  we  need  this  system?  Why? 

"VIMS  is  workable,  but  the  lag  time  makes  a lot  of  its  products 
useless  in  Workload  Control  and  Materiel  Control.  This  system  will 
give  fast  ...  service  in  both  these  sections.” 

"Yes.  In  order  to  be  able  to  give  the  maintenace  controller  the 
most  current  data  at  the  time  he  is  opening  a work  order." 

"Definitely  yes,  because  it  is  so  much  simpler  and  faster  than  the 
present  system.  It  also  saves  numerous  hours  of  maintenance  control 
t ime . " 


"Yes!  It  provides  us  with  immediate  processing  of  maintenance  and 
operations  data,  and  history  data  elements  required  for  management 
decisions  in  a quick  and  less  costly  way." 

NOTE:  There  were  no  negative  responses.  . 

10.  Do  you  have  any  other  comments?  f 

"I  can  see  big  improvements  in  the  Vehicle  Maintenance  reporting 
system  by  using  this  model  system,  and  would  enjoy  working  with  it." 

"I  enjoyed  being  involved  in  the  test  program;  however,  I would  like 
to  be  involved  in  the  final  development  of  the  program  and  help  put 
it  into  the  field." 

"I  will  be  glad  to  see  this  system  installed  as  quickly  as 
possible." 

"Should  be  put  into  use  as  soon  as  possible,  as  it  will  be  very  cost 
effective  to  the  USAF." 

"I  think  it  would  be  beneficial  to  include  people  from  the  field  in 
other  areas  of  development  of  this  concept  such  as  the  group 

rewriting  procedures,  and  establishing  analysis  and  reporting  » 

requirements  and  procedures." 


♦ 


122 


